Re: [PATCH] color: allow multiple attributes

From: Jeff King <peff@peff.net>
Date: Feb 28, 2010, 18:33 UTC
Message-ID: <20100228183349.GA24273@coredump.intra.peff.net>
In-Reply-To: <7vhbp1cjkc.fsf@alter.siamese.dyndns.org>

On Sun, Feb 28, 2010 at 10:16:19AM -0800, Junio C Hamano wrote:

Show 10 quoted lines

> > Hmm. Just a thought on the bit-setting approach, but does the order of
> > attributes ever matter? We are going to lose the ordering information
> > the user specifies, obviously.
> 
> True, I don't know if it matters.  I don't know if "blue bold bold" would
> result in bolder blue than "blue bold" on some terminal emulators, either.
> 
> I'd suggest that we ignore the issue for now, and when somebody complains
> with an actual non-working case, we would assess the damage that comes
> from this reordering to decide what to do next.  Parhaps a "non-working

I'm fine with that. FWIW, I tested and blink-before-ul and ul-before-blink look identical in an xterm. Certainly that's not the only terminal emulator people will use, but I expect it to be representative of the behavior of most emulators. I can dig my VT100 out of the attic if we want a real answer. ;)

> We were already losing the order by emitting attr then fg then bg even
> though attr can come before any colors (an undocumented side effect of a
> sloppy parsing logic, but some of the existing tests insist on kepping it
> working), by the way.

True. I also tested attr-before-color, then color-before-attr for both reverse and bold, and they look the same in an xterm. So I suspect it doesn't matter, and I'm too lazy to do more research unless somebody finds something that actually doesn't work.

-Peff