On Sun, Feb 28, 2010 at 10:16:19AM -0800, Junio C Hamano wrote: > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html