The completions for the `--example` option are generated using `find`.
The `find` utility on macOS will produce the following output when the
path argument has a trailing slash:
```
~/bat $ find ./examples/
./examples/
./examples//cat.rs
./examples//advanced.rs
./examples//simple.rs
./examples//list_syntaxes_and_themes.rs
./examples//yaml.rs
```
And will produce this output if the path does NOT have a trailing slash:
```
~/bat $ find ./examples
./examples
./examples/cat.rs
./examples/advanced.rs
./examples/simple.rs
./examples/list_syntaxes_and_themes.rs
./examples/yaml.rs
```
The extra slash after `examples` ends up in the completion suggestions
which is incorrect:
```
~/bat $ cargo run --example <TAB>
/advanced /cat /list_syntaxes_and_themes /simple /yaml
```
Unlike on my Linux box where `find` doesn't output the trailing slash:
```
~/bat $ cargo run --example <TAB>
advanced cat inputs list_syntaxes_and_themes simple yaml
```
Importantly, I get the same (correct) output on Linux even without the
trailing slash in the path argument to `find`.
This can give false positives but only if used on directories that
mix tracked and untracked files. The performance is better than
listing all tracked files, and in any case we're pretty far from a
correct solution that knows the target Git commit, so this seems like
good compromise.
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 spoke of "--bold" and "-b", which are two different things - "-b"
is short for "--background", bold is "-o".
Instead let's just mention the long versions of all the switches.
See #8053.
This only accepted "--background=". Really what we need to do is do an
actual getopt, but that wants a null-terminated array and is tightly
coupled to set_color.
Fixes#8053.
A bunch of our variables are only relevant for interactive use, but
this is two whole sections on them. Simply move them inside "Syntax
highlighting" and leave the link in Special Variables.
* Try to set LC_CTYPE to something UTF-8 capable
When fish is started with LC_CTYPE=C (even just effectively, often via
LC_ALL=C!), it's basically broken. There's no way to handle non-ASCII
characters with a C locale unless we want to write our
locale-independent replacements for all of the system functions.
Since we're not going to do that, let's try to find *some locale* for
LC_CTYPE.
We already do that in __fish_setlocale, but that's
- a bit of a weird thing that reads unstandardized system
configuration files
- allows setting locale to C explicitly
So it's still easily possible to end up in a broken configuration.
Now, the issue with this is that there is (AFAICT) no portable way to
get a list of all allowed locales and C.UTF-8 is not standardized, so
we have no one locale to fall back on and are forced to try a few. The
list we have here is quite arbitrary, but it's a start.
Python does something similar and only tries C.UTF-8, C.utf8 and
"UTF-8".
Once C.UTF-8 is (hopefully) standardized, that will just start
working (tm).
Note that we do not *export* the fixed LC_CTYPE variable, so external
programs still have to deal with the C locale, but we have no real
business messing with the user's environment.
To turn it off: $fish_allow_singlebyte_locale, if set to something true (like "1"),
will re-run the locale initialization and skip the bit where we force
LC_CTYPE to be utf8-capable.
This is mainly used in our tests, but might also be useful if people
are trying to do something weird.
Document the last few changes and move some of the things out of
"Interactive" into more specific categories. If it's to do with
completions, it goes into completions. Bindings? How about "Bindings"?
Chrome says that's better, presumably because it can then tell how
large the image is before it's loaded. Not that this tiny image really
is a massive problem, but let's be good, not acceptable.
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)
This has one slight behavioral change: Even with xsel, it now copies
to the clipboard, not the primary. I would imagine anyone who cares
about the primary selection has customized fish_clipboard_copy and
because we never got a bug about this not supporting anything but
xsel (and errorring out if it's not available!) this is probably
unused.
So now we support all the clipboard integration things, and we use the clipboard.
This change adds a binding that sets the s key's behaviour to match
the c key's in visual mode. This mirrors vim's behaviour (see `:h v_s`
in vim or neovim).
Apart from OpenBSD's "colorls" that is basically an ls that can do
color, there's also a ruby tool called "colorls" that's closer to exa.
Ignore that one since the options it understands are quite different
and I'm betting it's slower (given my experience with ruby tools).
See #8042.
* add support for colorized ls on openbsd
* add changelog line for colorls support
* add readme line for colorls support
* determine ls command at runtime, don't cache it
* eliminate __fish_ls_command function
