Re: [RFC] Indicate that Git waits for user input via editor

[Junio C Hamano <gitster@pobox.com>]

Lars Schneider <larsxschneider@gmail.com> 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.