threads / rfc / 47213

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

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

## tl;dr

16 messages between Nov 15, 2017 and Nov 19, 2017.

replies: 15people: 4as markdown or json

Lars Schneider· Nov 15, 2017, 15:08 UTC · lore
Hi,

Git gathers user input via text editor in certain commands (e.g. "git commit"). If you configure a text based editor, such as vi, then this works great as the editor is opened in your terminal window in the foreground and in focus.

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?

Thanks, Lars

Stefan Beller· Nov 15, 2017, 17:51 UTC · re: Lars Schneider · lore

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

On Wed, Nov 15, 2017 at 7:08 AM, Lars Schneider <larsxschneider@gmail.com> wrote:

Show 15 quoted lines
> Hi,
>
> Git gathers user input via text editor in certain commands (e.g. "git commit").
> If you configure a text based editor, such as vi, then this works great as the
> editor is opened in your terminal window in the foreground and in focus.
>
> 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?

Can this be put in a wrapper that opens the text editor? The wrapper would print these lines and then open the text editor; depending on the operating system, there might even be a command to focus on that editor window.

Regarding Git, maybe improve the documentation for how to set the editor variable?

>
> Thanks,
> Lars
Lars Schneider· Nov 15, 2017, 18:07 UTC · re: Stefan Beller · lore

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

Show 24 quoted lines
> On 15 Nov 2017, at 18:51, Stefan Beller <sbeller@google.com> wrote:
> 
> On Wed, Nov 15, 2017 at 7:08 AM, Lars Schneider
> <larsxschneider@gmail.com> wrote:
>> Hi,
>> 
>> Git gathers user input via text editor in certain commands (e.g. "git commit").
>> If you configure a text based editor, such as vi, then this works great as the
>> editor is opened in your terminal window in the foreground and in focus.
>> 
>> 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?
> 
> Can this be put in a wrapper that opens the text editor?
> The wrapper would print these lines and then open the text editor;
> depending on the operating system, there might even be a command to
> focus on that editor window.

Yeah, that would be a workaround. However, in order to take these steps (write the wrapper, enable the focus command) the users needs to understand the problem. That's quite a leap especially for new Git users. They just get the feeling "Git is broken because it hangs".

Can you imagine any downside for an "Opening editor for user input..." message?
> Regarding Git, maybe improve the documentation for how to set the editor
> variable?

The sad truth is that 98% of the users do not read the documentation (made up number but close to my observed reality).

- Lars
Stefan Beller· Nov 15, 2017, 18:37 UTC · re: Lars Schneider · lore

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

On Wed, Nov 15, 2017 at 10:07 AM, Lars Schneider <larsxschneider@gmail.com> wrote:

Show 11 quoted lines
>> Can this be put in a wrapper that opens the text editor?
>> The wrapper would print these lines and then open the text editor;
>> depending on the operating system, there might even be a command to
>> focus on that editor window.
>
> Yeah, that would be a workaround. However, in order to take these steps (write the
> wrapper, enable the focus command) the users needs to understand the problem.
> That's quite a leap especially for new Git users. They just get the feeling "Git
> is broken because it hangs".
>
> Can you imagine any downside for an "Opening editor for user input..." message?

"Wasting precious screen real estate for power users" (tm) So maybe if one can turn it off, this would be ok? Or even for known inline editors?

Show 5 quoted lines
>> Regarding Git, maybe improve the documentation for how to set the editor
>> variable?
>
> The sad truth is that 98% of the users do not read the documentation
> (made up number but close to my observed reality).

Yeah that is an excellent point, but you forgot the people who look at stackoverflow which of course links back to the docs in the first excellent reply.

In a way this suggestion of bettering the docs was a cheap way out, sorry.
Junio C Hamano· Nov 15, 2017, 22:32 UTC · re: Lars Schneider · lore

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

Lars Schneider <larsxschneider@gmail.com> writes:
Show 9 quoted lines
> 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.

Stefan Beller· Nov 16, 2017, 00:06 UTC · re: Junio C Hamano · lore

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

On Wed, Nov 15, 2017 at 2:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 34 quoted lines
> 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...");
"It takes quite some time to launch this special Git Editor"

As Lars pointed out, the editor may be launched in the background, that the user would not know, but they might expect a thing to pop up as a modal dialog as is always with UIs.

So despite it being technically wrong at this point in time, I would phrase it in past tense or in a way that indicates that the user needs to take action already.

The "Launching..." sounds as if I need to wait for an event to occur.
Show 13 quoted lines
>                 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.
Junio C Hamano· Nov 16, 2017, 00:33 UTC · re: Stefan Beller · lore

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

Stefan Beller <sbeller@google.com> writes:
Show 20 quoted lines
>> 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...");
>
> "It takes quite some time to launch this special Git Editor"
>
> As Lars pointed out, the editor may be launched in the background,
> that the user would not know, but they might expect a thing to
> pop up as a modal dialog as is always with UIs.
>
> So despite it being technically wrong at this point in time,
> I would phrase it in past tense or in a way that indicates that the
> user needs to take action already.
>
> The "Launching..." sounds as if I need to wait for an event to occur.

Heh, I wasn't expecting phrasing nitpicks when I was trying to help the thread by trying to come up with a way to avoid vertical space wastage.

Stefan Beller· Nov 16, 2017, 00:37 UTC · re: Junio C Hamano · lore

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

On Wed, Nov 15, 2017 at 4:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 26 quoted lines
> Stefan Beller <sbeller@google.com> writes:
>
>>> 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...");
>>
>> "It takes quite some time to launch this special Git Editor"
>>
>> As Lars pointed out, the editor may be launched in the background,
>> that the user would not know, but they might expect a thing to
>> pop up as a modal dialog as is always with UIs.
>>
>> So despite it being technically wrong at this point in time,
>> I would phrase it in past tense or in a way that indicates that the
>> user needs to take action already.
>>
>> The "Launching..." sounds as if I need to wait for an event to occur.
>
> Heh, I wasn't expecting phrasing nitpicks when I was trying to help
> the thread by trying to come up with a way to avoid vertical space
> wastage.

I know you weren't, but maybe it is helpful for the author of the patch (I presume you may not be the author, after all).

But you are right, I should have started with a more fundamental answer stating this is a good idea, and I cannot think of a negative side effect currently.

Junio C Hamano· Nov 16, 2017, 05:37 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
> I wonder if we can do something like
> ...
> to tentatively give a message without permanently wasting the
> vertical space.

Learning from 13e4760a ("recv_sideband: Do not use ANSI escape sequence on dumb terminals.", 2008-01-08), I think the above should be more like this:

	git_spawn_editor()
	{
		static const char *finish;
		if (!finish) {
			const char ANSI_FINISH[] = "\r\033[K";
			const char DUMB_FINISH[] = "done.\n";
			char *term = getenv("TERM");
			if (term && strcmp(term, "dumb"))
				finish = ANSI_FINISH;
			else
				finish = DUMB_FINISH;
		}
		/* notice the lack of terminating LF */
		fprintf(stderr, "Launched your editor, waiting...");
		fflush(stderr);
		if (!run_command(... spawn the editor ...))
			fputs(finish, stderr);
		else
			fprintf(stderr, "failed (%s)\n", strerror(errno));
		fflush(stderr);
	}
Junio C Hamano· Nov 16, 2017, 06:04 UTC · re: Lars Schneider · lore

[PATCH] launch_editor(): indicate that Git waits for user input

When a graphical GIT_EDITOR is spawned by a Git command that opens and waits for it for the user input (e.g. "git rebase -i") pops its window elsewhere that is obscure, the user may be left staring the original terminal window s/he invoked the Git command from, without even realizing that now s/he needs to interact with another window the editor is waiting in, before Git can proceed.

Show a message to the original terminal, and get rid of it when the editor returns.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * I tried this with "emacsclient" but it turns out that Emacs folks
   have already thought about this issue, and the program says
   "Waiting for Emacs..." while it does its thing, so from that
   point of view, perhaps as Stefan said originally, the editor Lars
   had trouble with is what is at fault and needs fixing?  I dunno.
   Also, emacsclient seems to conclude its message, once the editing
   is done, by emitting LF _before_ we have a chance to do the "go
   back to the beginning and clear" dance, so it probably is not a
   very good example to emulate the situation Lars had trouble with.
   You cannot observe the nuking of the "launched, waiting..." with
   it.
 editor.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
diff --git a/editor.c b/editor.c
index 7519edecdc..1321944716 100644
--- a/editor.c
+++ b/editor.c
@@ -40,6 +40,28 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
 		const char *args[] = { editor, real_path(path), NULL };
 		struct child_process p = CHILD_PROCESS_INIT;
 		int ret, sig;
+		static const char *close_notice = NULL;
+
+		if (isatty(2) && !close_notice) {
+			char *term = getenv("TERM");
+
+			if (term && strcmp(term, "dumb"))
+				/*
+				 * go back to the beginning and erase the
+				 * entire line if the terminal is capable
+				 * to do so, to avoid wasting the vertical
+				 * space.
+				 */
+				close_notice = "\r\033[K";
+			else
+				/* otherwise, complete and waste the line */
+				close_notice = "done.\n";
+		}
+
+		if (close_notice) {
+			fprintf(stderr, "Launched your editor, waiting...");
+			fflush(stderr);
+		}
 
 		p.argv = args;
 		p.env = env;
@@ -53,11 +75,14 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
 		sig = ret - 128;
 		sigchain_pop(SIGINT);
 		sigchain_pop(SIGQUIT);
+
 		if (sig == SIGINT || sig == SIGQUIT)
 			raise(sig);
 		if (ret)
 			return error("There was a problem with the editor '%s'.",
 					editor);
+		if (close_notice)
+			fputs(close_notice, stderr);
 	}
 
 	if (!buffer)
-- 
2.15.0-360-gf2497ca0e5
Lars Schneider· Nov 16, 2017, 10:25 UTC · re: Junio C Hamano · lore

Re: [PATCH] launch_editor(): indicate that Git waits for user input

> On 16 Nov 2017, at 07:04, Junio C Hamano <gitster@pobox.com> wrote:
Wow. Thanks for the quick patch :-)
Show 6 quoted lines
> When a graphical GIT_EDITOR is spawned by a Git command that opens
> and waits for it for the user input (e.g. "git rebase -i") pops its
> window elsewhere that is obscure, the user may be left staring the
> original terminal window s/he invoked the Git command from, without
> even realizing that now s/he needs to interact with another window
> the editor is waiting in, before Git can proceed.
Maybe:

When a graphical GIT_EDITOR is spawned by a Git command that opens and waits for user input (e.g. "git rebase -i"), then the editor window might be obscured by other windows. The user may be left staring at the original Git terminal window without even realizing that s/he needs to interact with another window before Git can proceed. To this user Git appears hanging.

> Show a message to the original terminal, and get rid of it when the
s/to/in/ ?
> editor returns.
Show 8 quoted lines
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
> * I tried this with "emacsclient" but it turns out that Emacs folks
>   have already thought about this issue, and the program says
>   "Waiting for Emacs..." while it does its thing, so from that
>   point of view, perhaps as Stefan said originally, the editor Lars
>   had trouble with is what is at fault and needs fixing?  I dunno.

Based on my (not too extensive) testing, Emacs is probably the only editor with this clever behavior.

Show 38 quoted lines
>   Also, emacsclient seems to conclude its message, once the editing
>   is done, by emitting LF _before_ we have a chance to do the "go
>   back to the beginning and clear" dance, so it probably is not a
>   very good example to emulate the situation Lars had trouble with.
>   You cannot observe the nuking of the "launched, waiting..." with
>   it.
> 
> editor.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> 
> diff --git a/editor.c b/editor.c
> index 7519edecdc..1321944716 100644
> --- a/editor.c
> +++ b/editor.c
> @@ -40,6 +40,28 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
> 		const char *args[] = { editor, real_path(path), NULL };
> 		struct child_process p = CHILD_PROCESS_INIT;
> 		int ret, sig;
> +		static const char *close_notice = NULL;
> +
> +		if (isatty(2) && !close_notice) {
> +			char *term = getenv("TERM");
> +
> +			if (term && strcmp(term, "dumb"))
> +				/*
> +				 * go back to the beginning and erase the
> +				 * entire line if the terminal is capable
> +				 * to do so, to avoid wasting the vertical
> +				 * space.
> +				 */
> +				close_notice = "\r\033[K";
> +			else
> +				/* otherwise, complete and waste the line */
> +				close_notice = "done.\n";
> +		}
> +
> +		if (close_notice) {
> +			fprintf(stderr, "Launched your editor, waiting...");

I also noticed that some people don't get that they need to save and close the file to continue. Plus, we should tell them that Git is waiting for *them* and not anything else. Maybe we should also tell them the editor name, but that might be too verbose. I dunno. How about this?

	fprintf(stderr, "Launched your editor ('%s'). Adjust, save, and close the file to continue. Waiting for you input... ", editor);
		
- Lars
Junio C Hamano· Nov 16, 2017, 14:58 UTC · re: Lars Schneider · lore

Re: [PATCH] launch_editor(): indicate that Git waits for user input

Lars Schneider <larsxschneider@gmail.com> writes:
>> On 16 Nov 2017, at 07:04, Junio C Hamano <gitster@pobox.com> wrote:
>
> Wow. Thanks for the quick patch :-)

Heh, this is not exactly my itch, so if you are inclined to, can you take it over from here on?

Thanks.
Lars Schneider· Nov 16, 2017, 15:24 UTC · re: Junio C Hamano · lore

Re: [PATCH] launch_editor(): indicate that Git waits for user input

Show 10 quoted lines
> On 16 Nov 2017, at 15:58, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Lars Schneider <larsxschneider@gmail.com> writes:
> 
>>> On 16 Nov 2017, at 07:04, Junio C Hamano <gitster@pobox.com> wrote:
>> 
>> Wow. Thanks for the quick patch :-)
> 
> Heh, this is not exactly my itch, so if you are inclined to, can you
> take it over from here on?

Absolutely! What is the proper way to proceed here? Should I send a v2 with the changes I suggested? How do I attribute you correctly? I assume I need to remove your 'Signed-off-by:'?

Thanks, Lars

Junio C Hamano· Nov 17, 2017, 01:09 UTC · re: Lars Schneider · lore

Re: [PATCH] launch_editor(): indicate that Git waits for user input

Lars Schneider <larsxschneider@gmail.com> writes:
Show 14 quoted lines
>> On 16 Nov 2017, at 15:58, Junio C Hamano <gitster@pobox.com> wrote:
>> 
>> Lars Schneider <larsxschneider@gmail.com> writes:
>> 
>>>> On 16 Nov 2017, at 07:04, Junio C Hamano <gitster@pobox.com> wrote:
>>> 
>>> Wow. Thanks for the quick patch :-)
>> 
>> Heh, this is not exactly my itch, so if you are inclined to, can you
>> take it over from here on?
>
> Absolutely! What is the proper way to proceed here? Should I send a v2
> with the changes I suggested? How do I attribute you correctly? I
> assume I need to remove your 'Signed-off-by:'?

If you are making major changes over the original patch, you'd probably want to take the authorship and mention me on Helped-by: and/or add "This is based on a previous work by...", if you want to credit me.

If you are not taking the authorship over, then doing something like
    https://public-inbox.org/git/xmqqshdex0ff.fsf@gitster.mtv.corp.google.com/
would be sufficient, I would think.
Thanks.
Kaartic Sivaraam· Nov 18, 2017, 17:47 UTC · re: Junio C Hamano · lore

Re: [PATCH] launch_editor(): indicate that Git waits for user input

On Thursday 16 November 2017 11:34 AM, Junio C Hamano wrote:
Show 14 quoted lines
> 
>   * I tried this with "emacsclient" but it turns out that Emacs folks
>     have already thought about this issue, and the program says
>     "Waiting for Emacs..." while it does its thing, so from that
>     point of view, perhaps as Stefan said originally, the editor Lars
>     had trouble with is what is at fault and needs fixing?  I dunno.
> 
>     Also, emacsclient seems to conclude its message, once the editing
>     is done, by emitting LF _before_ we have a chance to do the "go
>     back to the beginning and clear" dance, so it probably is not a
>     very good example to emulate the situation Lars had trouble with.
>     You cannot observe the nuking of the "launched, waiting..." with
>     it.
>

I tried this patch with 'gedit' and it seems to work fine except for one particular case. When the launched editor gets killed somehow when waiting for user input, the error message shown in the terminal seems to be following the "Launched editor..." message immediately, making it hard to identify it.

$ GIT_EDITOR=gedit ./git commit --allow-empty Launched your editor, waiting...error: gedit died of signal 15 error: There was a problem with the editor 'gedit'. Please supply the message using either -m or -F option.

Though this is not something that's going to happen very often, I'm not sure if this is to be considered. Just wanted to note what I observed.

Show 12 quoted lines
>   editor.c | 25 +++++++++++++++++++++++++
>   1 file changed, 25 insertions(+)
> 
> diff --git a/editor.c b/editor.c
> index 7519edecdc..1321944716 100644
> --- a/editor.c
> +++ b/editor.c
> @@ -40,6 +40,28 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
>   		const char *args[] = { editor, real_path(path), NULL };
>   		struct child_process p = CHILD_PROCESS_INIT;
>   		int ret, sig;
> +		static const char *close_notice = NULL;

Just a little curious, what's the advantage of making 'close_notice' 'static' over 'auto' ?

Show 20 quoted lines
> +
> +		if (isatty(2) && !close_notice) {
> +			char *term = getenv("TERM");
> +
> +			if (term && strcmp(term, "dumb"))
> +				/*
> +				 * go back to the beginning and erase the
> +				 * entire line if the terminal is capable
> +				 * to do so, to avoid wasting the vertical
> +				 * space.
> +				 */
> +				close_notice = "\r\033[K";
> +			else
> +				/* otherwise, complete and waste the line */
> +				close_notice = "done.\n";
> +		}
> +
> +		if (close_notice) {
> +			fprintf(stderr, "Launched your editor, waiting...");
> +			fflush(stderr);

Being curious again, is flushing 'stderr' required ? AFAIK, 'stderr' is unbuffered by default and I didn't notice any calls that changed the buffering mode of it along this code path.

Show 20 quoted lines
> +		}
>   
>   		p.argv = args;
>   		p.env = env;
> @@ -53,11 +75,14 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
>   		sig = ret - 128;
>   		sigchain_pop(SIGINT);
>   		sigchain_pop(SIGQUIT);
> +
>   		if (sig == SIGINT || sig == SIGQUIT)
>   			raise(sig);
>   		if (ret)
>   			return error("There was a problem with the editor '%s'.",
>   					editor);
> +		if (close_notice)
> +			fputs(close_notice, stderr);
>   	}
>   
>   	if (!buffer)
> 
Junio C Hamano· Nov 19, 2017, 01:07 UTC · re: Kaartic Sivaraam · lore

Re: [PATCH] launch_editor(): indicate that Git waits for user input

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:
Show 8 quoted lines
> $ GIT_EDITOR=gedit ./git commit --allow-empty
> Launched your editor, waiting...error: gedit died of signal 15
> error: There was a problem with the editor 'gedit'.
> Please supply the message using either -m or -F option.
>
> Though this is not something that's going to happen very often, I'm
> not sure if this is to be considered. Just wanted to note what I
> observed.
See my earlier response to Eric Sunshine.
>> +		static const char *close_notice = NULL;
>
> Just a little curious, what's the advantage of making 'close_notice'
> 'static' over 'auto' ?

A second call, if an earlier call to the function already determined that our standard error output is going to a terminal and what kind of terminal we are on, would just use the result from the earliser call.

> Being curious again, is flushing 'stderr' required ? AFAIK, 'stderr'
> is unbuffered by default and I didn't notice any calls that changed
> the buffering mode of it along this code path.

"By default" is the key phrase. The code is merely being defensive to changes in other area of the code.

← back to recent threads