From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: lars.schneider@autodesk.com, git@vger.kernel.org,
sbeller@google.com, sunshine@sunshineco.com,
kaartic.sivaraam@gmail.com, sandals@crustytoothpaste.net,
Lars Schneider <larsxschneider@gmail.com>
Subject: Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input
Date: Mon, 4 Dec 2017 12:30:24 -0500 [thread overview]
Message-ID: <20171204173024.GE13332@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqvahojssu.fsf@gitster.mtv.corp.google.com>
On Sat, Dec 02, 2017 at 09:15:29PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I tried to think of ways this "show a message and then delete it" could
> > go wrong. It should work OK with editors that just do curses-like
> > things, taking over the terminal and then restoring it at the end.
> > ...
>
> I think that it is not worth to special-case "dumb" terminals like
> this round of the patches do. If it so much disturbs reviewers that
> "\e[K" may not work everywhere, we can do without the "then delete
> it" part. It was merely trying to be extra nice, and the more
> important part of the "feature" is to be noticeable, and I do think
> that not showing anything on "dumb", only because the message cannot
> be retracted, is putting the cart before the horse.
>
> Since especially now people are hiding this behind an advise.*
> thing, I think it is OK to show a message and waste a line, even.
Yeah, I was tempted to suggest just dropping this terminal magic
completely. But it probably _does_ work and is helpful in the majority
of cases (i.e., where people have in-terminal editors). I dunno.
I am a little wary of hiding behind "but you can disable it with a
config option", because that's still a thing that users have to actually
do to get the previous behavior. And I expect to get some "ugh, git is
too chatty and annoying" backlash once this is in a released version.
But maybe that is just being paranoid. It's not like we don't have a lot
of other advice flags. I really could go either way on this whole thing
(but I'll be setting the advice flag myself ;) ).
> > An even worse case (and yes, this is really reaching) is:
> >
> > $ GIT_EDITOR='echo one; printf "two\\r"; vim' git commit
> > hint: Waiting for your editor input...one
> > Aborting commit due to empty commit message.
> >
> > There we ate the "two" line.
>
> Yes, I would have to agree that this one is reaching, as there isn't
> any valid reason other than "the editor then wanted to do \e[K
> later" for it to end its last line with CR. So our eating that line
> is not a problem.
Yeah, this was just me trying to come up with all possible implications.
I agree it's probably not worth worrying about.
-Peff
next prev parent reply other threads:[~2017-12-04 17:30 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-29 14:37 [PATCH v4 0/2] launch_editor(): indicate that Git waits for user input lars.schneider
2017-11-29 14:37 ` [PATCH v4 1/2] refactor "dumb" terminal determination lars.schneider
2017-11-30 20:30 ` Jeff King
2017-12-01 3:26 ` Kaartic Sivaraam
2017-11-29 14:37 ` [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input lars.schneider
2017-11-30 20:51 ` Jeff King
2017-12-01 3:56 ` Kaartic Sivaraam
2017-12-01 12:52 ` Lars Schneider
2017-12-01 18:29 ` Jeff King
2017-12-02 3:45 ` Kaartic Sivaraam
2017-12-03 16:39 ` Lars Schneider
2017-12-04 16:41 ` Kaartic Sivaraam
2017-12-04 17:26 ` Jeff King
2017-12-04 21:31 ` Lars Schneider
2017-12-04 21:42 ` Jeff King
2017-12-04 21:54 ` Lars Schneider
2017-12-04 22:09 ` Jeff King
2017-12-04 17:25 ` Jeff King
2017-12-03 5:15 ` Junio C Hamano
2017-12-03 12:47 ` Lars Schneider
2017-12-04 17:32 ` Jeff King
2017-12-04 21:34 ` Lars Schneider
2017-12-04 21:40 ` Junio C Hamano
2017-12-04 17:30 ` Jeff King [this message]
2017-11-29 18:35 ` [PATCH v4 0/2] " Thomas Adam
2017-11-30 13:55 ` Lars Schneider
2017-11-30 14:42 ` Thomas Adam
2017-11-30 15:13 ` Andreas Schwab
2017-12-01 3:41 ` Kaartic Sivaraam
2017-11-30 20:12 ` Jeff King
2017-11-30 20:51 ` Thomas Adam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171204173024.GE13332@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kaartic.sivaraam@gmail.com \
--cc=lars.schneider@autodesk.com \
--cc=larsxschneider@gmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=sbeller@google.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).