mirror of
https://github.com/fish-shell/fish-shell.git
synced 2026-04-25 04:11:14 -03:00
ba2ad33a81
Given that this curly underline will also be red, it should be widely
understood as error.
Since fish always renders immediately (and synchronously), typing "echo"
will briefly show an intermediate curly line. Maybe fish should redraw
after a timer elapses? This is probably unrelated to this patch.
As mentioned in cc9849c279 (Curly underlines in set_color and fish_color_*,
2025-04-13), there are still some terminals that interpret "\e[4:3m" as
something other than curly underline.
Some of them interpret it as background/foreground color, and some terminal
multiplexers downgrade it to straight underlines (which often happens due
to a false positive). I want to change this in multiplexers where possible
(see https://github.com/orgs/tmux/discussions/4477) but for now, disable
this feature in multiplexers (there are just a handful).
In a few years, those terminals will maybe agree with XTerm. Until then,
use XTGETTCAP as a temporary stepping stone. We could also read the terminfo
database but that will give only very few true positives, and lots of false
negatives. Better implement XTGETTCAP in the relevant terminals.
Note that if the universal variables use the "--track" flag (from the
grandparent commit), then
rm -rf /tmp/newhome
foot -e env $HOME=/tmp/newhome fish
xterm -e env $HOME=/tmp/newhome fish
will "magically work". For foot, $fish_color_error will have --underline=curly.
For xterm, it will not, due to the call to "fish_config theme update".
But of course since it's a universal variable, running fish in xterm
would also downgrade the fish running in other terminals.
Add a "fish_config theme save --yes" flag because "status xtgettcap"
requires stdin to be a terminal. I'd probably drop this requirement, and
make "status xtgettcap" always use fish's stdin and not its own. That'd be
cheating because an external command can't do that but I don't think this
change would be hurting anyone.
