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.
Now that we have modifiers and can have backgrounds and such, simply
setting it as css style doesn't cut it.
So let's stop validating for now, the worst that can happen is that
the color isn't rendered.
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.
Otherwise, with a light-theme, the selected entry uses black text with
"bright black" background, which can be low contrast thus hard to read.
The description background is different, maybe we can fix that later.
See #8376
This basically disables syntax highlighting. That doesn't mean we use
absolutely no colors - the search match, suggestion, selection and the
pager have coloring, but only reverse or brblack.
The idea is that this disables anything that tells you about
the *syntax*, but it still tells you about the state of the
commandline. If we didn't highlight the selection it would be entirely
invisible, and if we didn't highlight the suggestion you would have no
idea where it begins.
So this basically brings colors on-par with bash, where the search
match is colored (in reverse) and suggestions aren't a thing.
An alternative is to add a $fish_highlighting_enabled variable like
the one for suggestions. That's still possible, but would require some
internal changes to avoid coloring some things with $fish_color_normal
and other things with the normal terminal color.
One thing this also does not do is set the git prompt colors. These
are currently disallowed from being set in theme files because they
start with `__fish` instead of just `fish`. We should probably rename
them.
These are simple
var val [val val]
files. Basically the bit in `set -g fish_color_escape 86c1b9` after
the `set -g `. Since we're not going to `source` them, however,
arbitrary code and expansions are unsupported.
Also comments and such don't currently work.
This allows them to be easily readable both from webconfig (next
commit) and the shell (later).
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.
The buttons were already supposed to highlight on hover, but the color
difference was barely visible. Crank that up.
Also add a hover color to the tabs, colorschemes, prompts, functions.
The big clickable things.
This made the current prompt appear directly under the tab,
disregarding the padding.
That means it looked inconsistent with the colors. (note there's still
less padding on the side, but at least that allows more actual content
- prompts are often fairly wide)
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.
From my checks (gnome-terminal with the "gnome light" colorscheme)
this seems to be the only color that's barely visible in a light
terminal, and it's the only color mentioned in both bug reports.
I'm leaving the artistic decisions to others, this is now *acceptable*
in both.
Note that, because we use universal variables here (hint #7317), this
will only be changed for preexisting installations when the user
reloads the colorscheme.
Fixes#3412Fixes#3893
