Sounds like I should try this together with ametameric, which I've been using since I have protanomaly
Terminals should generate the 256-color palette
51–60 of 212 posts
Re: Terminals should generate the 256-color palette
#52The good thing with the 256c palette is that colors in the 16-255 range are fixed, which gives us a very high level of confidence that 146 will be a muted violet and so on. This is very useful for colorscheme developers because it allows us to provide a pretty good and consistent experience across the widest range of terminal emulators. If the 256c palette is generated from a -- potentially wild -- 16c palette then t…
> provide a [...] consistent experience Please just don't. This is not the web. Color usage in the terminal should be largely semantic, not stylistic. Speaking for the group of people I know and work with, we don't want a "consistent experience" and hate TUIs that try to manhandle the color palette. Use color sparingly and with intention. Respect that different people have different settings.
First, I make third-party Vim colorschemes, not app. People install my colorschemes because they like the colors, not because I'm a monster with a gun pointed at their face. No one is harmed. No one is forced to do anything they don't want.
Outside of my text editor, where colors matter a lot to me for syntax highlighting, I'm definitely in the NO_COLORS camp (and in the NO_EMOJI camp, nowadays).
> Color usage in the terminal should be largely semantic, not stylistic.
I wholeheartedly agree but 0-15 sadly have zero inherent semantics, which is the single reason behind every terminal colors-related drama since forever: developer choses 9 to highlight an error message because it is generally a bright red by default --> user sets 9 to whatever makes sense to them --> error message is illegible.
Re: Terminals should generate the 256-color palette
#53Terminals should be able to show images, so you could run Jupyter notebooks in them.
Sixel and ReGIS have been around for decades.
Re: Terminals should generate the 256-color palette
#54Earlier quoted context omitted.
I'm sorry, but I find this mentality from app developers extremely annoying. I personally prefer light themes everywhere, both in IDEs and in the terminal. I thought that just choosing my own color scheme for 0-15 would give me the color pallette that I prefer, but because app developers like you for some reason decided that you know better what colors do I prefer, this is actually not enough. I also have to configur…
I'm not an app developper. I make third-party colorschemes for Vim, which I assume are downloaded, installed, and used by people on their own volition, after they have looked at, and liked, the screenshots. Moreover, I take great care to make sure they are still usable in 16c, within reason. Because all my work is based on 16-255, I can actually guarantee to my users that, given a properly configured terminal emulato…
Why not truecolor if you want true colours?
Re: Terminals should generate the 256-color palette
#55Earlier quoted context omitted.
Terminals can show images https://sw.kovidgoyal.net/kitty/graphics-protocol/
Ok, maybe I should have said "framebuffers" instead of images. Because that Kitty protocol seems limited in that interaction was not one of their goals.
First example on the Kitty image protocol sent above looks pretty interactive:
Re: Terminals should generate the 256-color palette
#56Terminals should not exist, emulating a serial teletype emulating a Hollerith machine
That's 9front/Plan9. No actual terminals, but windows with shells.
Re: Terminals should generate the 256-color palette
#57I had exactly this thought!
Though, I have a problem with even just the basic 16 colours:
black red green yellow blue magenta cyan white bright black bright red bright green bright yellow bright blue bright magenta bright cyan bright white
~~~
Many themes take `black` to mean `black` and `white` to mean `white`. How is it supposed to work when one switches the theme between the dark and the light version?
What are `black`, `white`, `bright black`, and `bright white` supposed mean?
I take those as meaning (in order): `almost invisible on current terminal background`, `pretty contrasty`, `visible but not contrasty`, and `the contrastiest`.
I wish the colour names reflected that, instead of `black` and `white`: you usually care about the contrast, not about the precise colour.
Re: Terminals should generate the 256-color palette
#58This is a limitation of UNIX terminals, in other platforms not tied to a no longer existing tty interface, this isn't an issue. Unfortunely, given that we are stuck with UNIX derived OSes, this is indeed a possible issue. However I would argue, for fancy stuff there is the GUI right there.
Unix downvoters should have a look on 9front (the most featureful/supported plan9 fork out there) in order to realize that you can follow the Unix philosophy (even more than OpenBSD itself) tossing the VT100 emulators to the legacy 'vt' emulator if you want somehow use ancient software (or SSH) while setting actual graphical windows with the shell running inside with no terminals at all. No more damn control codes messing up everything. No more linebreaks. You can cut down your text with the mouse from day one. Even under Sam, which is something like a graphical Ed crossed with Notepad and much more powerful expressions than Ex/Vi ones.
Re: Terminals should generate the 256-color palette
#59Earlier quoted context omitted.
I'm not an app developper. I make third-party colorschemes for Vim, which I assume are downloaded, installed, and used by people on their own volition, after they have looked at, and liked, the screenshots. Moreover, I take great care to make sure they are still usable in 16c, within reason. Because all my work is based on 16-255, I can actually guarantee to my users that, given a properly configured terminal emulato…
Why not truecolor if you want true colours?
I don't want true colours. I want what I already have, 16-255, to stay reliable in the future.
Re: Terminals should generate the 256-color palette
#60This is a limitation of UNIX terminals, in other platforms not tied to a no longer existing tty interface, this isn't an issue. Unfortunely, given that we are stuck with UNIX derived OSes, this is indeed a possible issue. However I would argue, for fancy stuff there is the GUI right there.
I don't know any GUI that beats tmux work portability. Of course everything depends on exact nature of the work, but personally I would gladly leave text based interfaces behind, it's just that there's nothing better.
9front/plan9 leaves tmux and the like as toys. The moment you can use system tools, 9p and files on everything (even the text of the editor itself) you wont be back to these unusable teletype emulators, be XTerm clones or terminal multiplexors.