I find dark blue a specially hard to read choice. If there’s an option to switch to a better contrasting colour, it is well hidden. If such an option is not planned, all output colours should have medium brightness, which works in both dark and light mode! Edit: This uses (or falls back to using) the colour “bright blue” which one may be able to reconfigure.
Unicode
I delightedly discovered -Zrustc-unicode. Alas it uses a very ununicodey (IMHO ugly) hint underline ++++++++. Better options would be ╍╍╍╍╍╍╍╍, ┉┉┉┉┉┉┉┉, ┅┅┅┅┅┅┅┅, ════════,… Btw. miri’s compiler front end does not seem to be in sync with -Zrustc-unicode.
Highlighter
I’m thinking about an error and warning message highlighter for markdown. My feeling is that the default rust highlighter should also handle this. But if a majority feels a separate rust-diagnostic is a better fit, then so be it.
Before I even explore, my feeling is that the whole ecosystem (cargo doc, crates.io, docs.rs…) is not using the same source code highlighter. If that is true, are there plans to converge on any one?
What do you mean? My problem is not where to change it, but how? Some concrete info please! Anything cargo or rustc understands, I can set. But I find nothing in their doc.
None – this has nothing to do with terminals! I appreciate your effort of trying to help. At the same time I feel this is going in a useless direction.
I often just run this as a sub-command of Emacs M-& which sets TERM=dumb. (Not even in M-x compile as that would apply its own colouring.)
The Emacs terminal is still a terminal. Rustc just uses the standard 16-color palette escape sequences, what the colors actually map to is entirely up to the terminal. Rustc can’t do anything about it, or pick any RGB colors itself without using the extended 24-bit color escape sequences which aren’t supported by nearly all terminals out there. And it wouldn’t be a good idea anyway because any specific set of colors could clash with the user’s theme.
Given how customizable Emacs is, I’m sure there’s a way to set the 16-color terminal palette somewhere. The dark-blue-on-black illegibility is a well known problem with the "standard" palette.
Edit: I guess what rustc could do is avoid using the color number 5 altogether. I’m not sure why it’s used given the accessibility issues. Most terminals these days do default to less dark "dark blue" exactly for this reason though.
Edit2: Rustc could also choose to use one of the less dark blues from the 256-color "xterm" palette if the terminal supports it (and almost all do – not sure about Emacs term in "dumb" mode though, it may well be strictly vt100). So there are indeed ways that rustc could help make things better.
Thank you for the explanation, Johannes. I’ve lightened up my bright blue, so that it’s more bright than blue. (I had a cludgy workaround, but this is much better.) That’s it for my 1st point then – on to the really interesting other two!
That has the same issue as using 16-bit colors: you’re applying some hardcoded foreground color on top of a user-selected background (unless you also hardcode the background color and have it inconsistent with the rest of the terminal).
—
cargo doc and the docs output on docs.rs use the same highlighter (as the latter just runs the former), but yes the readme and docs.rs-specific source view uses a different highlighter, IIRC rustdocs highlighter is built on top of rustcs parser which isn’t really usable independently as part of docs.rs, so that uses other crates.
When using the base 16 colors, terminals let you change them and customize the look of your applications. When you use 256 and above, the application needs to provide customization options itself, and if you're not being very careful you can also end up with unreadable default text that can't be easily worked around (beyond things like red-green color blindness, if you customize text to be off-white with the expectation that the background is black, but it is white, you can easily end up with terrible contrast).
We have also gone out our way to cater to the lowest common denominator. That's why we haven't enabled unicode output yet either.
Re: Unicode, for those I think that the + underline is most appropriate, because it conveys the meaning of it better than plain underlines would. The meaning needs to be unambiguous even if color is disabled, so the underline needs to have double duty of covering a space and imply what the space is.
Re: highlighter, could you try rephrasing what you want? I'm having trouble understanding what it is you are asking for.
MacOS Terminal, which I use all the time, does not. I could use ITerm2 or whatever, but I don’t see a need because Terminal is fully adequate except for that minor detail (which has never ever been an issue because very very few programs use 24bit colors – except for one of my own programs, a demo running a software 3D renderer in terminal, and for the purposes of that demo, the 6x6x6 RGB cube in the standard 256-color palette is entirely fine).
That OS is no longer getting security updates so I'd strongly recommend not using it, especially since AI is helping find a lot more security flaws in everything than a few years ago. You can install a Linux distribution instead which should work well for most use cases and is up to date.
¡Hola Esteban! For the actual error and the related other places true Unicode underline is great. But are you saying: only for the suggestion Unicode underline is not clear enough? The whole thing is opt in anyway, but + is not Unicode, so it is not obeying the user’s choice.
My point is to be consistent: Either, by default, use ASCII, or, if the user wants, go all the way and make it all pretty! Each of the options variants I give, IMHO make for a clear underline. They all give a third style that differs from that used for the error and related places.
error[E0382]: borrow of moved value: `onds`
╭▸ tests/tests.rs:202:33
│
196 │ let onds = [OndDistance {
│ ──── move occurs because `onds` has type `[OndDistance; 1]`, which does not implement the `Copy` trait
‡
202 │ let o = onds; println!("{onds:?} {o:?}");
│ ┬─── ━━━━ value borrowed here after move
│ │
│ value moved here
╰╴
help: consider cloning the value if the performance cost is acceptable
╭╴
202 │ let o = onds.clone(); println!("{onds:?} {o:?}");
╰╴ ╍╍╍╍╍╍╍╍
