Re: %C(auto) not working as expected

From: Duy Nguyen <pclouds@gmail.com>
Date: Oct 10, 2016, 09:26 UTC
Message-ID: <CACsJy8CroyynVMctbPhuVr2VVQB7YyfcxDaMT25BikQ4R4We0Q@mail.gmail.com>
In-Reply-To: <20161009234617.y6xfjyv6xjkf2afi@sigill.intra.peff.net>

On Mon, Oct 10, 2016 at 6:46 AM, Jeff King <peff@peff.net> wrote:

Show 5 quoted lines

> On Sun, Oct 09, 2016 at 03:24:17PM +0200, René Scharfe wrote:
>
>> Offering a way to enable terminal-detection for all color codes of a
>> format would be useful, but using the existing "auto," prefix for that
>> would be a behaviour change that could surprise users.

I wonder if we made a mistake associating terminal-detection with %C(auto,...). The more likely use case is enable or disable all colors, not "the next tag".

Show 11 quoted lines

> Yeah. In retrospect, it probably would have been saner to make %C(red) a
> noop when --color is not in effect (either because of --no-color, or
> more likely when --color=auto is in effect and stdout is not a
> terminal). But that ship has long since sailed, I think.
>
> If we do a revamp of the pretty-formats to bring them more in line with
> ref-filter (e.g., something like "%(color:red)") maybe that would be an
> opportunity to make minor adjustments. Though, hmm, it looks like
> for-each-ref already knows "%(color:red)", and it's unconditional.
> <sigh> So perhaps we would need to go through some deprecation period or
> other transition.

We could add some new tag to change the behavior of all following %C tags. Something like %C(tty) maybe (probably a bad name), then discourage the use if "%C(auto" for terminal detection?

-- 
Duy