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
