Hello! Sorry for bothering about an unwanted feature and restoring an old thread, but posting this just for the information. There is a patched version (with 24bit color support) available in github https://github.com/spudowiar/rxvt-unicode/tree/24bit
Best regards, Anton Kochkov. On Sat, May 9, 2015 at 2:29 AM, Marc Lehmann <[email protected]> wrote: > 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 _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
