Re: [PATCH] launch_editor(): indicate that Git waits for user input
Kaartic Sivaraamwrites: > $ 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.
Re: [PATCH] launch_editor(): indicate that Git waits for user input
On Thursday 16 November 2017 11:34 AM, Junio C Hamano wrote: * 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. 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' ? + + 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. + } 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)
Re: [PATCH] launch_editor(): indicate that Git waits for user input
Lars Schneiderwrites: >> On 16 Nov 2017, at 15:58, Junio C Hamano wrote: >> >> Lars Schneider writes: >> On 16 Nov 2017, at 07:04, Junio C Hamano 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@gitster.mtv.corp.google.com/ would be sufficient, I would think. Thanks.
Re: [PATCH] launch_editor(): indicate that Git waits for user input
> On 16 Nov 2017, at 15:58, Junio C Hamanowrote: > > Lars Schneider writes: > >>> On 16 Nov 2017, at 07:04, Junio C Hamano 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
Re: [PATCH] launch_editor(): indicate that Git waits for user input
Lars Schneiderwrites: >> On 16 Nov 2017, at 07:04, Junio C Hamano 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.
Re: [PATCH] launch_editor(): indicate that Git waits for user input
> On 16 Nov 2017, at 07:04, Junio C Hamanowrote: Wow. Thanks for the quick patch :-) > 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. > Signed-off-by: Junio C Hamano > --- > > * 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. > 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