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

[Lars Schneider <larsxschneider@gmail.com>]

> 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