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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> I don't think it is a bad move overall. I use "pager.log" to pipe
> through a specific command (that is different than I would use for other
> commands).
>
> So I like the idea of configurability; the problem is just that it is
> happening at the wrong level.

The level at which configurability happens might be one issue
(i.e. you may want different pager for two operating modes for the
same command, hence your need to use "tag.list" not just "tag"), but
I think another issue is that it conflates if the output need to be
paged (on/off) and what pager should be used when the output is
paged.  When we see that a user sets "pager.tag", we should not have
made it an instruction to Git that _all_ output from "git tag" must
be paged.

If there were no need for supporting separate pagers per operating
mode of a Git command, say "git tag", you would not want to page the
output unless you are producing "git tag [-l]" listing.  You do not
want your interaction with the usual "git tag <name> [<an object>]"
to be paged, even if you want to use a pager different from GIT_PAGER
when you are viewing the tags.

It is good that each codepath can give default in this example

> The individual commands should be in
> charge of it, with something like:
>
>   setup_auto_pager("log", 1);
> ...
>   if (mode_list)
> 	  setup_auto_pager("tag.list", 0);

as the second parameter to setup_auto_pager(), but I think the first
parameter being "tag.list" vs "tag" is a separate issue.  Until
there comes another codepath in "git tag" that wants to call
setup_auto_pager(), it does not make any difference from the end-user's
point of view.  Starting with "tag.list" may futureproof it
(e.g. perhaps somebody wants to use a separate pager for "git tag --help"
and "tag.help" can be added without disrupting existing use of "tag.list")

So I think we are fundamentally on the same page; it is just you are
aiming higher than I was, but we both recognize the need for separate 
codepaths in a single command to decide if the output should be paged.

> I don't have a particular plan to work on it anytime soon, but maybe
> somebody could pick it up as relatively low-hanging fruit.

;-)