This fixes all but one of the warnings documented in issue #2685. The
sole remaining warning is from the
string split '' abc
example in doc_src/string.txt. That example results in the man page
displaying
string split {} abc
I leave it to someone else to fix that problem (I'll open an issue
specifically for it since it took some effort to track down the source
of the warning).
Resolves issue #2685.
It used to be that way and we recommend `set fish_greeting` (i.e. set to
empty) in the docs - possibly since we check if the variable is defined
on upgrade.
Rather than storing short and long options separately, using
a complicated set of invariants, store them in a single string
and use an explicit type complete_option_type_t to track how they
are interpreted.
This was a "cache" of dubious value that was also very confusing.
The idea was to express in one place all of the short options that
were allowed for a command, in a big string. But it's simpler to
just construct that on-demand by walking the list of
complete_entry_opt_t.
Also remove some other dead code as part of cleanup.
This is meant to make it clear that fish cannot control the terminal
window background color. It also augments the set_color documentation to
describe how it decides which color the terminal can display.
Resolves#2421.
Resolves#2184.
To implement this mostly as a wrapper around pactl, we add the list of
commands for this to that. It's 90% the same anyway. (This means that
`pactl suspend ` will complete files instead of commands like `pactl
banana ` would, but neither is correct)
This fails on e.g. an abbr that uses `env a=b`, like the included test demonstrates.
Unfortunately it decreases the speed again (2s vs 2.2s vs 4s original),
but correctness is more important.
- Replace __fish_abbr_escape with `string escape`
- Don't double-parse the key
- Replace IFS magic with string
Together, this seems to speed it up by a factor of about 2.
Unfortunately, nvim will, even when running in a terminal that supports
it, swallow the sequences whole, rendering the displayed text _white_.
This means falling back to 256 colors is the lesser evil as at least a
blue-ish color will display as blue while a red-ish will be red, instead
of both showing white.
nvim's behavior does _not_ change depending on
$NVIM_TUI_ENABLE_TRUE_COLOR or any other option I could find and neovim-qt
exhibits the same behavior.
Fixes#2600.
The fix for #2075 inadvertently started unescaping the strings emitted
from `commandline -b`. Only strings emitted with the `-o` flag are
supposed to be unescaped.
Fixes#2210.
