My phone uses dotted underline to indicate errors; that seems nice, a bit
less aggressive than curly. Unfortunately dotted underlines are not as well
supported in terminal emulators; sometimes they are barely visible. So it's
unlikely that we want to use --underline=dotted for an important theme.
Add double and dashed too I guess, even though I don't have a concrete
use case..
Add a new underline-color option to set_color (instead of adding an optional
color argument to --underline); this allows to set the underline color
independently of underline style (line, curly, etc.). I don't think this
flexibility is very important but this approach is probably the least hacky.
Note that there are two variants:
1. \e[58:5:1m
2. \e[58;5;1m
Variant 1 breaks:
breakage from colon-variant for colored underlines
- cool-retro-term makes text blink
- GNU screen (goes into bold mode)
- terminology (goes into bold mode)
Variant 2 would break:
- mintty (Cygwin terminal) -- it enables bold font instead.
- Windows Terminal (where it paints the foreground yellow)
- JetBrains terminals echo the colons instead of consuming them
- putty
- GNU screen (goes into bold mode)
- st
- urxvt
- xterm
- etc.
So choose variant 1.
Closes#11388Closes#7619
set_color --underline=curly outputs \e[4:3m which breaks the following
terminals:
- Terminal.app interprets it as yellow background
- abduco and dvtm interpret it as green foreground
- JetBrains terminals interprets it as yellow background
- urxvt interprets it as yellow background
terminals that interpret curly as single underline:
- tmux [1]
- emacs ansi-term [2]
- emacs vterm
- GNU screen (also wrongly turns on italic mode)
- terminology (also wrongly turns on italic mode)
- Vim's :terminal
[1]: https://github.com/orgs/tmux/discussions/4477
[2]: https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-04/msg01093.htmlCloses#10957
Our use of the terminfo database in /usr/share/terminfo/$TERM is both
1. a way for users to configure app behavior in their terminal (by
setting TERM, copying around and modifying terminfo files)
2. a way for terminal emulator developers to advertise support for
backwards-incompatible features that are not otherwise easily observable.
To 1: this is not ideal (it's very easy to break things). There's not many
things that realistically need configuration; let's use shell variables
instead.
To 2: in practice, feature-probing via terminfo is often wrong. There's not
many backwards-incompatible features that need this; for the ones that do
we can still use terminfo capabilities but query the terminal via XTGETTCAP
directly, skipping the file (which may not exist on the same system as
the terminal).
---
Get rid of terminfo. If anyone finds a $TERM where we need different behavior,
we can hardcode that into fish.
* Allow to override this with `fish_features=no-ignore-terminfo fish`
Not sure if we should document this, since it's supposed to be removed soon,
and if someone needs this (which we don't expect), we'd like to know.
* This is supported on a best-effort basis; it doesn't match the previous
behavior exactly. For simplicity of implementation, it will not change
the fact that we now:
* use parm_left_cursor (CSI Ps D) instead of cursor_left (CSI D) if
terminfo claims the former is supported
* no longer support eat_newline_glitch, which seems no longer present
on today's ConEmu and ConHost
* Tested as described in https://github.com/fish-shell/fish-shell/pull/11345#discussion_r2030121580
* add `man fish-terminal-compatibility` to state our assumptions.
This could help terminal emulator developers.
* assume `parm_up_cursor` is supported if the terminal supports XTGETTCAP
* Extract all control sequences to src/terminal_command.rs.
* Remove the "\x1b(B" prefix from EXIT_ATTRIBUTE_MODE. I doubt it's really
needed.
* assume it's generally okay to output 256 colors
Things have improved since commit 3669805627 (Improve compatibility with
0-16 color terminals., 2016-07-21).
Apparently almost every actively developed terminal supports it, including
Terminal.app and GNU screen.
* That is, we default `fish_term256` to true and keep it only as a way to
opt out of the the full 256 palette (e.g. switching to the 16-color
palette).
* `TERM=xterm-16color` has the same opt-out effect.
* `TERM` is generally ignored but add back basic compatiblity by turning
off color for "ansi-m", "linux-m" and "xterm-mono"; these are probably
not set accidentally.
* Since `TERM` is (mostly) ignored, we don't need the magic "xterm" in
tests. Unset it instead.
* Note that our pexpect tests used a dumb terminal because:
1. it makes fish do a full redraw of the commandline everytime, making it
easier to write assertions.
2. it disables all control sequences for colors, etc, which we usually
don't want to test explicitly.
I don't think TERM=dumb has any other use, so it would be better
to print escape sequences unconditionally, and strip them in
the test driver (leaving this for later, since it's a bit more involved).
Closes#11344Closes#11345
This parser was pretty nice but it has some issues with the new syntax.
It's not really needed when most bindings use the new syntax.
Let's remove it altogether.
This except clause was too narrow, so it would fail here even on other
systems just because webbrowser.get() returned nothing usable
Now it will fail *later* with "could not locate runnable browser", but
at least it won't say anything about chromeos on non-chromeos systems.
Since the new expanded abbreviations in 3.6.0, abbr no longer accepts
new universal variables. That means this tab is now
non-functional (except that it could technically remove abbrs that
were set in universal variables).
Because making it work with the expanded abbreviations requires some
awkwardness like a dedicated conf.d snippet (or writing into
config.fish!), we simply remove it.
"socket.has_ipv6" is basically useless - it tells you python has
been *compiled* with ipv6 support.
Instead just try ipv6 and if that fails with EAFNOSUPPORT (checking
the actual errno), try v4.
Yes, I explicitly do not care to test this on python2.
Fixes#3857
This is a follow-up to #8811, which fixed fish_config on newer versions of
Sailfish OS.
Using the previous method to open the fish_config URL on Sailfish OS worked
only on 4.4 (and 4.3 IIRC), but not on older OS versions. Opening the URL
using xdg-open works well with new and old OS version, and has been tested on
- Sony Xperia 10 II running SFOS 4.4 aarch64
- Sony Xperia XA2 Ultra running SFOS 4.4 armv7hl
- Sony Xperia X running SFOS 4.1 armv7hl
- Jolla Phone running SFOS 3.4 armv7hl
Closes#8872
The `name` attribute I used in commit f725cd402d
is undocumented, and [someone discovered] that it does not exist for one
possible browser on MacOS. This should make the code work correctly even in that case.
This probably doesn't currently cause a problem, at least when
`isMacOS10_12_5_OrLater()` is true, because of the ordering of the if
statements in the `runThing` function.
[someone discovered]: https://bugs.python.org/issue43424#msg409087
If the theme says "brgreen", that's what we want the variable to say
after.
This used to translate it through our palette, so it ended up as
00ff00, which isn't the same.
This still keeps the idea that colors that aren't in the palette are
better, and it does it in a slightly roundabout way (translate color
string to rgb string, see if the rgb string is a key in that
translation dictionary), but it should work for now.
Theoretically if this only includes simple characters, it won't cause
any issues. We already validate in other places but it doesn't hurt to
do this twice.
This just simply passed the "color" value, which is just the
foreground color string.
Instead, we pass the actual object back, with the modifiers as bools
and foreground/background separate.
Our themes don't use background a lot, except in the pager, so this
never really came up.
We only need the curses module to look up sgr0, bold and underline
sequences.
Since those are going to be the xterm versions 90% of the time, we can
simply use those if this fails.
Fixes#8487.
This used to pass each color in a separate url-encoded request, which is
just wasteful.
Also it passed separate parameters for modifiers like bold and
underlined, but never gave them actual values. Instead the color is
passed as one string.
So we just use json, and then iterate over it server-side.
Recently Safari seems to hang with fish webconfig. This is apparently
because Safari is opening a socket and not writing to it, causing
webconfig to hang until the timeout (30 seconds). It's not clear why.
Use ThreadingMixIn so that FishConfigTCPServer can handle more
than one connection at a time. This fixes the hang under Safari.
These were hard to read in the browser, but not in the terminal.
The palette in color.cpp lists #000080 for blue, which is *even darker*. I'm not sure if that's actually a thing - I was under the impression that table was taken from xterm.
Either way, listing it in this color doesn't do anyone any favors. It's just a rough approximation anyway.
Otherwise this has filesystem order, which on my system is quite
chaotic.
An alternative would be to randomize the order so people see different
prompts each time.
This gets fish to print the right prompt of any sample if it has any,
and then shows it separately.
If there is a right prompt, it will also save it. If not, it will *not* overwrite an existing right prompt.
When `fish` is running in the Chrome OS Linux VM (Crostini),
both `help` and `fish_config` opened a "file not found"
page. That is because on Crostini, `BROWSER` is usually set to
`garcon-url-handler`, which opens URLs in the host OS Chrome
browser. That browser lacks access to the Linux file system.
This commit fixes these commands. `help` now opens the URL on
www.fishshell.com. `fish_config` now opens the URL for the
server it starts. Previously, it opened a local file that
redirects to the same URL.
In the case of `help`, the situation could be improved further
by starting a web server to serve help. I don't know of another
way to access `/share/fish` from outside the VM without user
intervention, and I think that might be a part of the security
model for the Crostini VM.
It's hard to write a test for this. I checked that `help math`,
`python2 webconfig.py`, and `python3 webconfig.py` work on my
machine running in Crostini.
