I have set TERM=xterm-256color or TERM=konsole-256color, either one fails to render the base16 256 vim colorscheme and the colortest shows a discrepancy on the last colors all showing as blue in konsole vs xterm/urxvt ( see images attached ). Reproducible: Always Steps to Reproduce: 1. launch konsole 2. run colortest from base16-shell 3. Actual Results: display som 256 colors as blue Expected Results: display 256 colors properly https://github.com/chriskempson/base16-vim http://imgur.com/OMQsWsk
Created attachment 91086 [details] konsole on left, xterm on right the blue colors on the bottom is where the issue lies
I can confirm on Kubuntu 14.10 using Konsole 2.14.1.
By default, colors 16-21 should be shades of blue, exactly as you see in Konsole. The problem is that certain terminal emulators let you redefine any of the 256 palette entries arbitrarily to any rgb colors - konsole doesn't. I assume that your script relies on this feature and redefines the colors to something very different from their original values.
(In reply to Egmont Koblinger from comment #3) > By default, colors 16-21 should be shades of blue, exactly as you see in > Konsole. > > The problem is that certain terminal emulators let you redefine any of the > 256 palette entries arbitrarily to any rgb colors - konsole doesn't. I > assume that your script relies on this feature and redefines the colors to > something very different from their original values. Does this mean that adding the ability to change those colors will be a no-fix?
Dunno, I'm not konsole's developer. My 2 cents: This whole palette approach is braindamaged and broken on so many levels... It was probably 1997 when I replaced my 1MB video card (which allowed me either 16 bits per pixel (5+6+5 per color) @800x600, or palette-based 8 bit per pixel @1024x768 (the palette always being adjusted to the active window, the rest looking totally broken) by a 2MB card that allowed 16 bits @1024x768. Since they I'm grateful I never had to look back to palette mode. In case of terminals: Your app can try to query or modify the palette – you can't be sure if it'll work, it depends on the terminal. Moreover, querying the palette is an asynchronous operation, you'll get a response later, and e.g. if you work over ssh, you can't be sure what that "later" means. If you have a timeout, you're already prone to race condition. Okay, you can issue the querying and then the setting escape sequences, and see later whether you happen to get a response. Cumbersome to implement, and I don't know if any library (e.g. ncurses) helps you here or if there's any app actually doing this. Querying is of course necessary to be able to restore the palette when the app quits. Still it will be left in modified state if your app crashes (but then other properties of the terminal are not restored either, so it'd not that bad). Palette approach doesn't allow an app to use any color that it wants to (as e.g. directed by an external source, e.g. html viewer that wants to show you the page in its actual colors), see also https://www.midnight-commander.org/ticket/1849. Palette approach can't work in terminal multiplexers with side-by-side windows (e.g. tmux), unless you're willing to see faulty colors in the non-active screens (as I did with my desktop 18 years ago) or unless the multiplexer translates the palette colors into direct RGB when it talks to the underlying actual terminal emulator (in which case users would complain that it ignores their terminal emulator's color settings). Palette approach mangles the look of the scrollback buffer, so ideally it's only useful for fullscreen apps that switch to the alternate screen where there's no scrollback buffer. Some terminal emulators still allow you to access the normal screen's scrollback when you're on the alternate screen, though, so it'd still look broken there. Many people claim that direct RGB is an overkill and who needs 16M colors at the same time anyway? My desktop monitor can't even show 16M colors at the same time either. They miss the point that it's not about showing this many colors at once; it's about showing any of the colors at any time, without independently from the rest of the screen. They also miss the point that colors of the 256-color palette are still way too far from each other. IMO, ideally, every graphical terminal emulator would implement true color support, and every app would allow you to use these colors directly (in addition to keeping the 8/16/256 legacy palette colors). Unfortunately there's a huge resistance in implementing this feature from authors of many terminal emulators, and from the authors of the two most popular screen drawing libraries: ncurses and slang. Actually, these libraries internally also think in terms of palette (what a shame) and would have to be significantly redesigned/extended to support RGB (see e.g. https://www.midnight-commander.org/ticket/3264). I'm personally quite disappointed to see that even 20-ish years after desktops switched from palette to RGB, many people still think it's an overkill in terminals and wish to get stuck in the ancient historical world. Here's a great summary of the state of true color support; I've no clue how up-to-date it is: https://gist.github.com/XVilka/8346728. Anton (the maintainer of that page) and me tried to push for this feature about a year ago, but we seemed to hit a wall. The feature didn't reach the critical support to become mainstream, and unfortunately seems to remain an extra which is randomly supported by some scattered terminals/apps. In an ideal world, your terminal emulator would support 16M true colors (it does since you use konsole which supports it) and so would your app (I'm afraid it doesn't yet, but maybe will one day) and you'd configure your app to use these. The it could use base16 (or whatever) without ever mangling the palette.
OK, so how do I use konsole's colorscheme file to redefine colors 16-21 then? Is there another way to set these colors the proper konsole way? Currently konsole seems to be the only one not supporting this.
*** This bug has been confirmed by popular vote. ***
This looks like a duplicate of bug 233991
I see this bug hasn't gotten any attention for a long time, but it's actually a pretty big problem with how Konsole handles color. Every other truecolor supporting terminal emulator that I am aware of has palette colors 16-21; only Konsole does not. Bug 233991 only concerns Konsole inability to set the ANSI color palette using escape sequences -- a capability it absolutely should have, possibly leaving the user a configuration option to override the palette with Konsole's own color scheme. However, the issue here is that there are six colors in Konsole's ANSI color palette which are not set by the terminal *at all*. There is no way to supply them in a .colorscheme, which is currently the only way to configure colors.
I think I somehow skipped over Egmont Koblinger's comments when I read the comment chain, because clearly I was missing a lot of information. Still a +1 for setting the palette with escape sequences from me. Konsole is one of the only terminal emulators I've used that can't have its colors set by base16-shell.