Re: [PATCH 1/2] pager: move pager-specific setup into the build

From: Jeff King <peff@peff.net>
Date: Aug 1, 2016, 18:07 UTC
Message-ID: <20160801180707.rw6drvk5dsgy6joi@sigill.intra.peff.net>
In-Reply-To: <CACsJy8CLNtbAvRxVtX_9qZ0cahce7cFfk=wh78Wm99Qf5B8HRw@mail.gmail.com>

On Mon, Aug 01, 2016 at 08:01:13PM +0200, Duy Nguyen wrote:

Show 15 quoted lines

> > If you are interested, I suggest you read the thread linked earlier:
> >
> >   https://public-inbox.org/git/52D87A79.6060600%40rawbw.com/T/#u
> >
> > which discusses this and other issues. But basically, I think you cannot
> > really solve this without getting intimate with each pager (which people
> > seemed not to want to do).
> 
> Cooking pager specifics in git does sound bad. But it does not have to
> be that way. What if we delegate the decision whether to color or not
> to a script (e.g. by setting color.ui= "script <path to the script>")?
> The script has all the info (env variables, uname, user preference...)
> and can make a better decision than 'is stdout a tty?'. It's not about
> out of the box experience, more towards customization (without
> fragmenting .gitconfig files too much).

It sounds like we are solving two separate problems.

I was mostly concerned with the out-of-the-box experience. E.g., you build git and run "git log" and it prints out gibberish, either because of your $PAGER or your $LESS settings (which you might have set years ago).

For more advanced usage like yours, I'd shove any personal logic into a wrapper around your pager script. I think the particular decision you want, though, is related to color.pager, which is outside that scope. I'm not sure exactly what your setup looks like, but I wonder if it would be served by better config support (i.e., why do you need a script to dynamically look at your pager and see if color.pager should be turned on; can't you configure both at the same time?).

-Peff