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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 28, 2017, 04:29 UTC
Message-ID: <xmqqpo836n6u.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171127230520.GA29636@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> ... "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....
> 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).

Yes, I think we already had that discussion and if you recall those involved in the thread except Lars were in favor of writing this off as "here is a nickel--get a better editor".

One thing that may sway you slightly in favor of doing this in Git is that a new user _might_ not be expecting Git to open an editor in response to the command s/he just gave it [*1*].

It is one thing that the user _knowingly_ runs an editor and fails to locate which window the editor opened. It is a bit different if the user didn't even know that s/he is supposed to be interacting with an editor.

Show 8 quoted lines

> But I also recognize that the world isn't perfect. Not all editors will
> get this right, and not all users are savvy enough to set up a wrapper
> script for editors which don't. So defaulting this to "on" tries to help
> those cases.
>
> If the anti-cruft techniques I mentioned above work well in practice,
> then we get to have our cake and eat it, too. If they don't, then I'm
> not sure if the tradeoff is worth it.

I agree with all of the above; I do not know if the "go back and erase to the end of the line" is good enough in practice, and that is why I sent "here is a possible anti-cruft" but did not push it strongly forward myself.

[Footnote]

*1* "git merge topic" used to just complete the merge with canned
    log message and people were not all that unhappy--they just
    thought it is an OK design that a clean merge is a
    non-interactive operation.  Perhaps a person new to Git may be
    expecting that behaviour (without knowing anything like (1) that
    was what we used to do or (2) we open an editor by default these
    days), wondering why nothing seems to be happening, staring at
    an inactive window, after typing "git merge topic".