Web lists-archives.com

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

On Mon, Nov 27, 2017 at 06:05:20PM -0500, Jeff King 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".

I myself would also set such an option.  More importantly, I think there
are other developers who would complain about such a message, and I'd
like to give them an easy way to turn it off.

Note that I am not altogether opposed to advice.*, since I personally
find it helpful in certain cases as an aide-mémoire of what state my
branch is in.

> 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

I agree that the editor is the right place to put this, but I also
understand that the people most likely to be helped by this are the
least likely to write such scripting.  I think this is especially so
because in my experience newer, less advanced users are more likely than
not to use graphical editors.

Git is an extraordinarily powerful piece of software, but it's also hard
for people to use (judging by my Twitter feed), so if we can make it
less painful for new users, I'm okay with an advice.* setting.

I'm slightly negative on hard-coding emacsclient, since I'm sure someone
will come up with another editor that does the same thing, and then we'd
have to update it.

> 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 have a feeling that this may not work properly in editors that don't
support the concept of xterm alternate screens (such as the Linux
console) where the editor window is left on the screen, but it may be
that it works fine and I've just misunderstood how it's supposed to
work.  It may also be that we don't care about such cases, as any cruft
would have already scrolled off the screen.
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

Attachment: signature.asc
Description: PGP signature