This 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 me…
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.
I know UNIX since being introduced to it via Xenix in 1992 thereabouts, and never found a use for tmux. More so, I use the terminal as strictly necessary and nothing more.
I don't want "a terminal", I want a command based interface combined with being able to use the same set of tools/commands on all the files I interact with.
Like, it gets taken for granted, but being able to literally grep my html file, my program source and my readme file, instead of having to open a separate gui program and using its bespoke seach menu feature, is really, really nice.
There are downsides of course, like the way we keep jamming everything into the square hole that is 1980s terminal emulators and character based displays, but frequently this is worth it.
This 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 me…
(I didn't downvote you.) Plan 9 made some really cool design decisions, and I keep looking for places to use 9P. I also believe that Plan 9, as an artifact of its era, bet too heavily on the mouse and pixel-mapped graphics. Text, character-cell terminal emulation, and SSH won for good reasons. "GUI > terminal" is a separate matter from "Plan 9 > Unix".
In some important ways, even text with hacky escape codes is more useful and more robust than a fundamentally graphical interface. Text scales up and down with display size and pixel density. Text works over high-latency links and enables simple latency compensation like in Mosh. Text gives you universal copy-paste. Text is more accessible for humans and for machines.
I use a virtual terminal daily on my phone. If we literally used rio GUIs designed around the three-button mouse and desktop pixel density, it would be a lot less ergonomic. I'd like to see a successor to the VT220 lineage, but it's easier to imagine it built on text.
I think your wish is self-contradicting. `#fff` is so-called _device_ colour -- a device like a LED-based display uses it directly to drive the LEDs, where `#fff` means that the red, the green and the blue channel are already "cranked to 11". The `f` here is equivalent to 11. HDR uses a different color format, I think -- exactly because `#fff` is otherwise either ambigous, or has to map to a different colour gamut --…
It's pretty obvious that gp is asking for the brightest blue to be as bright as the brightest white but no brighter. And no, #fff is not a "device color". The syntax originates from the web where sRGB is implied ever since we had displays brighter than that.
It wasn't obvious to me -- I misread "blue" as "white".
`#fff` is device color, it's short for `#ffffff` which is 24-bit RGB that predates sRGB, as does true color device support. I was sending 24-bit RGB to VESA-compliant graphics cards before sRGB became a thing. `#fff` was supported by Photoshop and Macromedia products as straightforward device colour format, before sRGB was adopted by at least the latter, mind you. The use by CSS is co-incidental, not where the format was introduced.
I think your wish is self-contradicting. `#fff` is so-called _device_ colour -- a device like a LED-based display uses it directly to drive the LEDs, where `#fff` means that the red, the green and the blue channel are already "cranked to 11". The `f` here is equivalent to 11. HDR uses a different color format, I think -- exactly because `#fff` is otherwise either ambigous, or has to map to a different colour gamut --…
I meant #fff as the nominal white point, which is not the brightest white the device can produce. It's how #fff is displayed on Firefox on an otherwise HDR screen. Assuming the screen is not set to max brightness and otherwise HDR capable, it means that it's not the max brightness an individual pixel/subpixel can produce, so desaturating blue color just to make it brighter can be an unnecessary compromise only dictat…
I have been blind and read your "blue" as "white", sorry. Most of my comment only makes sense in that umm, light, pardon the pun.
Can you link to your Vim colorschemes? I have a light and a dark one that I hacked over the years but I'm always looking for new ones.
Can you share your light one? I've never been able to find a white background scheme I actually love, rather than tolerate...
I prefer my background dark so light colorschemes are not really an area I've explored seriously. Also, dark colorschemes are much easier to design than light ones due to the disproportionate amount of light a white, say, background emits compared to the amount emitted by text. It dramatically reduces the number of colors you can use.
Really interested in this for cargo/rustc. We run into issues where we need one or two more colors but all that is left after going for the basic semantic colors is magenta (odd choice), and black and white (not safe without inspecting the theme).
Other than red and green, for semantic reasons, a CLI tools shouldn’t bother with colors. And it should support text markers instead of colors for the occasional piping.
That's what cargo/rustc do: all of the information is conveyed through text, but colors are used to make it easier to scan. It ends up using almost every usable base-16 color: red for the error marker and their primary spans, yellow for warnings and their primary spans, blue for secondary spans, the gutter separator and line numbers, bold text for the main message, cyan for notes and their primary spans, green for helps and their primary spans, green and red for structured suggestions, bright magenta for very specific hand-picked highlights (used to be bold/bright white, but that wasn't obvious enough in lots of terminals, used semantically equivalent to bold or italics in text, the case most people will encounter these in is in E0308 type errors where a specific type parameter didn't match) and white for anything else. Note that of the mentioned output the only thing that is differentiated in color only is the message highlights, and that's because it is generally done for either extra clarification ("Trait is not implemented for Foo, but it is implemented for Bar") or within code that we wouldn't want to pollute with additional non-code ASCII markers (people should be able to copy&paste those types without causing parse errors). Some people deride this variety as being too "christmas tree", but IMO it works quite well for scanning output. Color helps a lot when scanning longer lists and dense output. Colors might not help much if the tool is emitting a single line of output for each event, but rustc emits dozens of lines per error. And no, reducing the amount of output would not be the answer for rustc, you can already use `--message-format=short` if you want that, or try/contribute to one of the TUI projects consuming the json output for dynamic navigation of the output (to expand and contract sections). rustc and cargo default configuration have to cater to the most common case, while also keeping the number of non-essential features (like a built-in TUI) to a minimum.
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…
That's okay. Because the user has to reach out and choose a colour scheme they like, you can assume if they installed your colour scheme, they like the colours.
I agree. I always customize the blue color on my terminal because dark blue on black is completely unreadable to me (and I'm not even color blind!). For some reason, every single terminal emulator defaults to a blue that's unreadable on a black background (I think typically #00f). If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
Most of them are emulating the EGA/VGA palette which was a regression from the CGA terminal colors. https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...
Not really, because the dark yellow (not brown) is used... it's similar, but not the same in most terminals... brown as dark yellow for cga was a kind of short to a different color mix than the natural position which most terminals now use... actual screen effectiveness/brightness is different as well.
Kind of anal about this since I started with a lot of CGA and EGA displays when I was in my late teens and early 20s and relatively involved in the ANSi art scene.
Here's a related project I'm working on for playing doors in a web browser.