git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Lars Schneider <larsxschneider@gmail.com>
Date
Nov 22, 2017, 16:53 UTC
Message-ID
<919EA31C-FDC5-4694-9614-157042D2DA82@gmail.com>
In-Reply-To
<CAPig+cQ3a0guJUhnbktrjs6fL6mSrUXmPqR0BafEAOhVr7Sy-w@mail.gmail.com>
Show 48 quoted lines
> On 17 Nov 2017, at 20:41, Eric Sunshine <sunshine@sunshineco.com> wrote:
> 
> On Fri, Nov 17, 2017 at 8:51 AM,  <lars.schneider@autodesk.com> wrote:
> 
>> +                       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 ('%s'). Adjust, save, and close the "
>> +                               "file to continue. Waiting for your input... ", editor
>> +                       );
> 
> Here's what this looks like for me:
> 
> --- 8< ---
> Launched your editor
> ('/Applications/Emacs.app/Contents/MacOS/bin/emacsclient'). Adjust,
> save, and close the file to continue. Waiting for your input...
> Waiting for Emacs...
> --- 8< ---
> 
> Very, very noisy, so much so that it's almost unreadable. There are at
> least three reasons for the noise:
> 
> * The raw message itself is already overly long. Do we really need to
> assume that newcomers are so clueless that they need it spelled out to
> such a level of detail? "Launched editor" should be enough for most
> people, and one would hope that "Launched editor; waiting for
> input..." would be enough for the rest.
> 
> * Does not take into consideration that EDITOR might be very long;
> perhaps you could just print the basename and strip arguments (i.e.
> "/my/long/path/edit -x --foo --zap" becomes "edit"). Or, just omit the
> editor altogether.

Agreed already in another reply here: https://public-inbox.org/git/0DD1EE8A-47F1-41AA-8F86-C9FDF99D22A0@gmail.com/

Show 5 quoted lines
> 
> * emacsclient already prints its own message ("Waiting for Emacs...",
> which runs together with Git's message). Perhaps treat emacsclient as
> a special case and skip printing this message if emacsclient is in
> use: if (strstr(...,"emacsclient"))

If Junio et al. are ok with the special handling of emacs, then I am happy to add this change in v3. If we look for "emacsclient", then would this cover emacs on Linux and Windows, too? (I am no emacs user)

Show 46 quoted lines
> 
> And, of course, with a "dumb" terminal, it's even noisier with the
> extra "done." at the end:
> 
> --- 8< ---
> Launched your editor
> ('/Applications/Emacs.app/Contents/MacOS/bin/emacsclient'). Adjust,
> save, and close the file to continue. Waiting for your input...
> Waiting for Emacs...
> done.
> --- 8< ---
> 
> As Junio pointed out in [1], emacsclient has already emitted a
> newline, so the clear-line sequence is ineffective; likewise, for a
> dumb terminal, "done." ends up on its own line. Aside from the noise,
> this also suggests making a special case for emacsclient.
> 
> And, as Junio pointed out in [2], with a message so long, once it has
> wrapped, the clear-line sequence does not work as intended. For those
> of us with 80-column terminals, we're left with a bunch of noise on
> the screen.
> 
>> +                       fflush(stderr);
>> +               }
>> 
>>                p.argv = args;
>>                p.env = env;
>> @@ -53,11 +79,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);
> 
> Should printing of close_notice be done before the error()? Otherwise,
> you get this:
> 
> --- 8< ---
> Launched your editor (...) ...There was a problem...
> --- 8< ---

I think we should keep it as I agree with Junio's argument here: https://public-inbox.org/git/xmqqh8tsqs83.fsf@gitster.mtv.corp.google.com/

- Lars
Previous: Junio C HamanoNext: Eric Sunshine
Message 11 of 12 in “launch_editor(): indicate that Git waits for user input”
  1. launch_editor(): indicate that Git waits for user inputlars.schneider@autodesk.com, Nov 17, 2017
  2. Junio C HamanoNov 17, 2017
  3. Lars SchneiderNov 22, 2017
  4. Eric SunshineNov 17, 2017
  5. Junio C HamanoNov 18, 2017
  6. Kaartic SivaraamNov 19, 2017
  7. Junio C HamanoNov 20, 2017
  8. Lars SchneiderNov 22, 2017
  9. Kaartic SivaraamNov 22, 2017
  10. Junio C HamanoNov 24, 2017
  11. Lars SchneiderNov 22, 2017
  12. Eric SunshineNov 22, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.