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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 22, 2016, 17:19 UTC
Message-ID: <xmqqfuor6ee3.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160922064730.277nzkqlxbcx2kjg@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

> 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

Show 7 quoted lines

> 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.

;-)