Re: Bug: pager.<cmd> doesn't work well with editors

From: Jeff King <peff@peff.net>
Date: Sep 20, 2016, 01:47 UTC
Message-ID: <20160920014733.7whjuxfuimx5ztdb@sigill.intra.peff.net>
In-Reply-To: <xmqqh99bho7a.fsf@gitster.mtv.corp.google.com>

On Mon, Sep 19, 2016 at 09:03:05AM -0700, Junio C Hamano wrote:

Show 10 quoted lines

> Anatoly Borodin <anatoly.borodin@gmail.com> writes:
> 
> >> I think, the pagination should be turned off when the editor is being
> >> called.
> 
> This is a fun one.  IIRC, we decide to spawn a pager and run our
> output via pipe thru it fairly early, even before we figure out
> which subcommand is being run (especially if you do "git -p
> subcommand"), which by definition is way before we know if that
> subcommand wants to let the user edit things with the editor.

Right. Once the pager is spawned, it is too late to change things (even if we spawned the editor directed to /dev/tty, it would be racily competing for input with the pager).

And this isn't really limited to the editor. It's more _annoying_ with the editor, but really "pager.tag" does not make any sense to set right now, because it is handled outside of the "tag" command entirely, and doesn't know what mode the tag command will be running in. So it's _also_ the wrong thing to do with "git tag foo", which doesn't run an editor (but you don't tend to notice if you use "less -F" because the pager just quits immediately).

So you really only want to page tag-listing (and the same for branch, config, etc). A long time ago I had a patch to add "pager.tag.list", and the tag command would decide whether and how to page after realizing it was in listing mode. Looks like I did send it to the list:

  http://public-inbox.org/git/20111007144438.GA30318@sigill.intra.peff.net/

though I think there are some rough edges (like handling "git stash list").

I also wonder if there are any commands that actually have more than one sub-command. So another option would be to teach the main git.c a blacklist of "do not respect pager config" commands (like tag), and then tag itself could decide to respect pager.tag at the right moment.

I think that makes things worse for a third-party command, though; we cannot know whether a script "git-foobar" dropped into the $PATH would like us to respect pager.foobar or if it would prefer to decide itself later.

-Peff