Earlier 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.
Terminals should generate the 256-color palette
111–120 of 212 posts
Re: Terminals should generate the 256-color palette
#112Re: Terminals should generate the 256-color palette
#113For my ncurses brothers, saw this but have not used yet: https://github.com/dankamongmen/notcurses
For my plan9 brothers: one day we will have a new acme, written in common lisp and displaying all the correct colors, and lo it will be glorious.
Re: Terminals should generate the 256-color palette
#114Earlier quoted context omitted.
If I was the maintainer of a terminal emulator, I would see a quite obvious way to improve the situation for my users: change the default colors so that dark blue is brighter. There's no obvious way to unilaterally improve the situation across the whole ecosystem, that's true. But I don't understand why individual terminal emulator maintainers don't fix it for their users.
Because it means making choices, breaking assumptions, etc.. They have made it user-customizable so they don't have to go through all that. FWIW, the current de-facto standard is set by xterm. Here is a relevant excerpt of its source code: ! Disclaimer: there are no standard colors used in terminal emulation. ! ! The choice for color4 and color12 is a tradeoff between contrast, depending ! on whether they are used fo…
Re: Terminals should generate the 256-color palette
#115Earlier quoted context omitted.
No one can and people have been complaining about it for decades. But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation. And no urgency either, because all terminal emulators allow users to customize the palette anyway.
There are fewer blue cones in the fovea centralis than there are in the surrounding parts of the macula, so humans can't resolve details as well in blue light.
Re: Terminals should generate the 256-color palette
#116Earlier quoted context omitted.
Do you think xorg and weston dont support more than 16 colors? You just run a different terminal emulator.
So I need a terminal emulator to see colours? On Windows I just open a window and put colours in it.
Re: Terminals should generate the 256-color palette
#117The 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…
I would posit then that this article simply doesn't apply to you at all. The feature being described is targetted at users who are effectively developing their own schemes (albeit in a rather simplified automated manner). If I'm taking something off the shelf, I'm using the appropriate recommended base16. I have no expectation that a wild base16 is going to align with any 3rd-party's curated scheme.
I do understand that this logic isn't always going to click with people given the differing contexts of a terminal-wide -vs- app-specific (i.e. vim) approach, but again: that disparity seems either a legacy issue (caused by things like this 16-256 mis-alignment) OR simply a philosophical difference (whereby people who customise at the term level shouldn't at the app level & vice-versa).
Re: Terminals should generate the 256-color palette
#118The 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.
Re: Terminals should generate the 256-color palette
#119Terminals 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
#120Earlier quoted context omitted.
Is that really optimal? It is already true in that case that your colour schemes do not work for people with opinionated colour settings. Isn't this just relying on a quirk? The point of not using truecolor is to respect the colour preferences of the user. XKCD 1172? https://xkcd.com/1172/
It has been working for decades and I would rather have it keep working for decades to come. What would be optimal is semantic _styles_ (not colors): - The developer marks the string "XXX" as an error message without even trying to style it. - The platform/user agent/terminal/whatever displays the string in the default style for "error". - The user can adjust the theme of their platform/user agent/terminal/whatever t…