Hi,
>> Although I had already mentioned about this feature (konsole-style
>> true color support) on some places with my bad English, now I try to
>> say my opinion repeatedly in other words.
>
> Can you post these other places? I would like read these threads
> and know what another persons think about it. And don't worry
> about your english, mine is worse ;).
iTerm2: Support for 3-byte color mode
https://code.google.com/p/iterm2/issues/detail?id=218
#11 and #16 are my posts.
vim_dev: [PATCH] Gui colorschemes in terminal
https://groups.google.com/d/msg/vim_dev/ed0GTyYrSYg/tu1npMY2Ew0J
I have a respect for the dedication of promoters of this feature,
however I feel regretful that their way is wrong.
>
>> Please don't break backward compatiblity of VT emulators.
>
> I don't know if there are some another sequences to CSI 38 and CSI 48,
> but if they were not then these new sequences don't break any
> compability. Can you give a bit more information?
It is clear thing if you imagine that existing terminals interpret Konsole-style SGR sequence.
It will cause various unexpected effects to character attributes, and even though
it may cause terrible "shift-out" effect(character corruption) in some ISO-2022 terminals(such as VT).
In historical view, 256 paletted SGR sequence "CSI ; 38 ; 5 ; Ps m" is the original cause of this problem.
This cursed sequence is proposed by someone who interpreted ITU T.416 in an inappropriate way.
This breaks the design of SGR and backward compatibility.
Now Konsole and some terminals have followed this bad habit.
>
>> Above my opinion might be not constructive, so now I propose alternate sequences:
>>
>> I recommend a recall of Konsole style truecolor control seqences, and propose to change them as follows:
>>
>> CSI 38 ; 2 ; Pr ; Pg ; Pb m -> CSI ? Pr ; Pg ; Pb $ m
>> CSI 48 ; 2 ; Pr ; Pg ; Pb m -> CSI = Pr ; Pg ; Pb $ m
>
> They can conflict with private extensions.
Yeah, certainly there are some possibilities that they conflict with existing private sequence of someone's terminal.
Ok, just I also propose DSR query/answer sequences for testing if they are available.
Query:
CSI ? 8893 n - Query whether 24bit color sequences are ready
Reply:
CSI ? 8894 n - Ready
CSI ? 8895 n or no responses - Not ready
> I don't like the idea of
> using the private space for a extension that surely will be part
> of all the terminals.
I used private area intentionally. I think new experimental control sequences should be in private space.
For example, DEC and Xterm did so. We should update ISO if we want to add a new sequence in public space.
>> I'm happy if above proposal would be accepted because my terminals and
>> some my tools can ignore them properly by considering ISO-6429.
>
> I don't understand why you can not ignore CSI 38 ; 2 ; Pr ; Pg ; Pb m,
> because any sequence that it is not understood must be ignored.
Yes, any sequence that it is not understood must be ignored.
But "CSI 38 ; 2 ; Pr ; Pg ; Pb m" is well-formed SGR, and remember that SGR has "accumulative" design.
We don't know we should ignore what range of parameters because original SGR don't have the concept of "combined parameters".
It is natural that each parameters are to be interpreted or ignored individually.
-- Hayaki Saito
Received on Thu Oct 30 2014 - 17:38:58 CET