On Thu, May 07, 2015 at 08:56:16PM +0200, Marcin Kurczewski <[email protected]>
wrote:
> Hmm... perhaps we describe it wrong; let me try again. While indeed we
> can map some predefined colors to any RGB we want through user
> settings, and runtime - by escape codes such as "\e]10...", it is
> limited only to a few colors - we can change foreground, background or
> any color in the 16 color palette, but that's it.
Both xterm and urxvt let you change any colour, not just the first 16 ones,
and afaics, for many many years, too.
I don't know about other temrinals, but I'd be surprised if other
temrinals had such a limitation either.
> change the palette after printing something to terminal, what we
> printed will change colors, too. This is ultimately the thing we're
That is the point, yes.
> 1. to be able to print any color in RGB cube,
And as explained, you can already do that, you are not limited to the
colours in the 88 or 256 colour palette.
> 2. to have more colors to choose from than 88/256 Xterm color palette,
And as explained, this is already the case.
> 3. to be independent from 16 color palette / user settings, so that
> what we printed stays the same, regardless of settings changes that
> might come before or after.
Again, this 16 colour palette limit does not exist anywhere, afaics.
> I apologize if this is already implemented in any way.
As explained multiple times, it's all imnplemented already, and for a long
time.
There is no need to apologise, but it would help if you stopped stubbornly
ignoring when we tell you that it is already implemented. I feel like a
broken record epxlaining this again and again.
What is not going to be implemented is a full 24 bit palette - you are and
will be limited to ~88 or ~256 simultaneous colours at any one time. To
lift this limit, we would need a good reason why 256 colours is not enough
- "I can make toy rainbows with libcaca" is not going to cut it.
> I also understand if printing colored stuff in a way that completely
> disregards user palette settings sounds bad to you.
One would expect that ultimately, the user was in control, yes.
> talk about the same thing. (And again, personally I see no harm in
> adding support for such a custom extension that's to be used not too
> seriously.)
Me neither, but there is no "such a custom extension" at this point, there is
not even a specification for what such a custom extension would do. To even
*begin* to talk about such an extension you'd first have to explain what it
is supposed to do.
Simply askign again and again to implement "something" without telling
what this something is, and ignoring people trying to be helpful in
explaining how you can already do what you want is not leading anywhere.
Implementing an extension that is incompatible to other terminals *is*
harmful.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
