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

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

From
Lars Schneider <larsxschneider@gmail.com>
Date
Nov 28, 2017, 12:31 UTC
Message-ID
<33DF54BF-8483-4DFC-99B8-4B25883FE28C@gmail.com>
In-Reply-To
<20171127230520.GA29636@sigill.intra.peff.net>
Show 31 quoted lines
> On 28 Nov 2017, at 00:05, Jeff King <peff@peff.net> wrote:
> 
> On Mon, Nov 27, 2017 at 08:09:32PM +0000, brian m. carlson wrote:
> 
>>> Show a message in the original terminal and get rid of it when the
>>> editor returns.
>> [...]
>> 
>> Sorry for coming to the topic so late, but it occurred to me that we
>> might want to conditionalize this on an advice.* flag.  I expect there
>> are some people who will never want to see this, and letting them turn
>> it off would be good.
> 
> I am torn between saying "yes please, I would absolutely set such an
> option myself" and "if we need advice.*, that is a good sign that the
> feature is mis-designed".
> 
> Let me elaborate a bit on the latter.
> 
> My gut feeling is that this is absolutely the wrong place to put a
> message like this. We don't know enough about what the editor is doing,
> so we have to take pains to avoid a crufty message in the terminal,
> including:
> 
>  - playing ANSI-term trickery to erase the message
> 
>  - hard-coding (!) emacsclient as a special case
> 
> And that's why I say that "advice.*" is a bad sign, because it means
> those other techniques are failing, and somebody is seeing and being
> annoyed by the cruft.

I agree with your cruft assessments, especially regarding the hard-coded emacsclient thingy.

However, I really like Brian's "advice" suggestion. Would you be more in favor of this change if we don't do emacsclient hardcoding and rely on "advice.openEditor"? Maybe we could also remove the term trickery but this seems to be convenient in practice.

According to the docs advice.* defaults to "true". For my use case it would be ok if "advice.openEditor" would default to "false" as I distribute a common Git config via "include.path" to my users. However, that is likely confusing to the "advice" machinery and users.

> The right place for this message, IMHO, is for the editor itself (or a
> wrapper script) to say "hey, I'm opening a new window" (like emacsclient
> does).
I 100% agree. However, as you mentioned, the world isn't perfect.

Git's core concepts are pretty simple and most people understand them if you explain them visually. However, applying/using these concepts is often the problem. If you want to use Git efficiently then you need to know lots of other things. Being command-line savvy is one of them. From experience I know that this is hard for many people. Especially Windows users as they are not used to BASH and Unix-like command-line tools. That's why I think "advice.openEditor" could help a few people.

- Lars
Previous: Junio C HamanoNext: brian m. carlson
Message 8 of 11 in “launch_editor(): indicate that Git waits for user input”
  1. launch_editor(): indicate that Git waits for user inputlars.schneider@autodesk.com, Nov 27, 2017
  2. Kaartic SivaraamNov 27, 2017
  3. Eric SunshineNov 27, 2017
  4. Lars SchneiderNov 27, 2017
  5. brian m. carlsonNov 27, 2017
  6. Jeff KingNov 27, 2017
  7. Junio C HamanoNov 28, 2017
  8. Lars SchneiderNov 28, 2017
  9. brian m. carlsonNov 29, 2017
  10. Junio C HamanoNov 27, 2017
  11. Lars SchneiderNov 28, 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.