Re: [PATCH] color: allow multiple attributes

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

quoted

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