Re: [PATCH] launch_editor(): indicate that Git waits for user input
- From
Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
- Date
- Nov 18, 2017, 17:47 UTC
- Message-ID
- <26256555-4463-7bc9-5d07-8617932cf6cb@gmail.com>
- In-Reply-To
- <xmqqr2syvjxb.fsf@gitster.mtv.corp.google.com>
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)
>