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.
If you have a prompt preceded by a new line, you'll get a line full of spaces instead of an empty line above your prompt. This doesn't make a difference in normal usage, but copying and pasting your terminal log becomes a pain. This commit clears that line, making it an actual empty line.
The random builtin command may or may not produce values with a truly
random distribution. So make the documentation reflect that reality. Also,
make the command consistent with similar shells (e.g., bash, zsh) which
produce a range of [0..32767].
Resolves issue #1272.
Before this change, `fish ./test.fish` would fully resolve the
relative paths and symlinks of test.fish, as reported by `status -f`.
However `source` would not. With this change, both cases return relative
paths. `realpath` may be used by scripts to resolve them.
Fixes#2643
This patch is currently floated from the NixOS side as part of
https://github.com/NixOS/nixpkgs/pull/12000, but prior versions of the
hook ignore anything but the first argument anyway, so this is
backwards-compatible.
* Add a note to the `--wrap` docs saying that wrapping only works when
specifying completions for commands, not for paths.
* Add more info about how `--arguments` is handled.
* Indicate which options can be repeated in the usage lines.
* Reorder the options in usage slightly to group better.
* Reorder the option descriptions to match the order as seen in usage.
* Update some of the option descriptions.
* Fix the documentation for -C to show that it must be `-CSTRING`
instead of `-C STRING`.
* Document the behavior of `-C` with no argument.
* Tweak some of the explanatory text after the option list.
* Delete `--authoritative` and `--unauthoritative` from the
documentation entirely. Those options appear to not actually do
anything in the new parser.
This skips the weird dance where we'd define a simple handler and then
later overwrite with a fancier one, once the first event came in.
It turns out that isn't necessary, as it doesn't actually improve
startup speed because the checks needed to define fancier handlers are fast.
In case we are non-interactive, still define the simple handler, and
keep the default handler for users to switch to.
