ZyX,
I respect to your huge efforts for this works.
I saw the default value of KS_8F/KS_8B in built-in caps for xterm is
"Konsole-style".
> +# ifdef FEAT_TERMTRUECOLOR
> + {(int)KS_8F, IF_EB("\033[38;2;%lu;%lu;%lum", ESC_STR
> "[38;2;%lu;%lu;%lum")},
> + {(int)KS_8B, IF_EB("\033[48;2;%lu;%lu;%lum", ESC_STR
> "[48;2;%lu;%lu;%lum")},
> +# endif
Please consider that Konsole-style 3-byte color mode extension(separated by
semi-colon) is not ISO-8613-3 compatible.
Konsole just followed in past Xterm's wrong footsteps(semi-colon separated 256
color sequence).
Now I fear that this sequence brings us confusion because it breaks backward
and forward compatibility.
The detailed reasons of this is explained here.
http://code.google.com/p/iterm2/issues/detail?id=218#c16
These days, xterm seems to trying amending past mistakes.
For example, the bogus mouse reporting sequence can be replaced by "SGR style”,
the bogus OSC title sequence (it can include C1 control character) can be
replaced with "title mode”.
And now, Xterm accepts colon separators with 256color/3-byte-color sequence.
I approve of this efforts for that improvements of xterm. At least we shouldn't
make things worse any more.
Please take attention for above‐mentioned issues.
One more question,
Why do you use direct 3-byte color sequence, instead of
doing dynamic palette operation using initc("\e ] 4 ; r ; g ; b \e \”) which
already defined by terminfo.
I think most of color schemas don't require more than 256 colors at once.
Best regards,
— Hayaki Saito
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
