Lars Schneider <larsxschneider@xxxxxxxxx> writes:
> However, if you configure an editor that runs outside your terminal window then
> you might run into the following problem:
> Git opens the editor but the editor is the background or on another screen and
> consequently you don't see the editor. You only see the Git command line
> interface which appears to hang.
>
> I wonder if would make sense to print "Opening editor for user input..." or
> something to the screen to make the user aware of the action. Does this sound
> sensible to you? Am I missing an existing solution to this problem?
My knee-jerk reaction was: for such a user who has EDITOR set to a
program that pops under, wouldn't any program, not just Git, that
uses the editor to open a file for editing/viewing look broken?
Would we care if we are called "broken" by such a clueless user who
cannot tell a (non-)broken caller of an editor and a broken editor?
But that is true only when the user does realize/expect that the
program s/he is running _will_ open an editor at the point of the
workflow. If s/he types "git merge" or "git rebase -i @{u}", for
example, it is true that the world would be a better place if s/he
knows that would ask a file to be edited with an editor, but it is
unrealisic to expect that everybody knows how to operate these
commands. Everybody is a newbie at least once.
I wonder if we can do something like
git_spawn_editor()
{
const char *EL = "\033[K"; /* Erase in Line */
/* notice the lack of terminating LF */
fprintf(stderr, "Launching your editor...");
fflush(stderr);
if (!run_command(... spawn the editor ...)) {
/* Success! - go back and erase the whole line */
fprintf(stderr, "\r%s", EL);
} else {
fprintf(stderr, "failed (%s)\n", strerror(errno));
}
fflush(stderr);
}
to tentatively give a message without permanently wasting the
vertical space.
