On Fri, Jan 06, 2023 at 06:21:41PM +0000, Nicholas Marriott wrote: > You should strictly only discard the following two arguments or stuff like > SGR 38;5;100;1 won't work.
Well I was initially in two minds about that, because I thought there might be other un-official extensions that used 38 with a varying number of parameters. But I haven't found any apart from 5 followed by one argument, and 2 followed by three RGB values, so yes I agree with you on this. However, since this morning I've been working on actually implementing 256 colour support so the next version of the patch will parse SGR 38;5 sequences correctly. Presumably though, if we see SGR 38;X where X is neither 2 nor 5, we still have to discard everything, right? Because that would be an invalid sequence and we don't know for sure whether anything that comes after it is actually intended as regular control codes or parameters for something else. I.E. SGR 38;5;X - we set colour X. SGR 38;2;X;X;X - we discard three parameters, then continue parsing. SGR 38;Y; - where Y is 'something else', we ignore everything until the 'm'. Or is there a better way? Regarding 256 colour support, I've got it working, (on 32bpp displays only), but there are two open questions: 1. On displays that don't support 256 colours, (e.g. VGA console), what should SGR 38;5;X do? I currently have it set so that it selects colours 0-7, and for 8-255 just does nothing, (leaves the current colour). 2. We implement bold as brighter text rather than a bold font. This doesn't work very well with a 256 colour palette. We can't just +8 to get a bright version of the colour. How should bold work with arbitrary colours? > This is why some people prefer the : form but the ship has rather sailed on > that. I'm assuming that we don't really need to implement the : form? Thanks again for the feedback.
