Prior to this change, abbreviations were stored as fish variables, often
universal. However we intend to add additional features to abbreviations
which would be very awkward to shoe-horn into variables.
Re-implement abbreviations using a builtin, managing them internally.
Existing abbreviations stored in universal variables are still imported,
for compatibility. However new abbreviations will need to be added to a
function. A follow-up commit will add it.
Now that abbr is a built-in, remove the abbr function; but leave the
abbr.fish file so that stale files from past installs do not override
the abbr builtin.
Introduced with 3.6.0 `fish_cursor_selection_mode` variable breaks
existing vi bindings (for example, input sequence `abc<Esc>0vd` doesn't
delete the `a` character as would be expected).
This patch fixes it by switching `fish_cursor_selection_mode` to
`inclusive` and back.
When this was introduced, we used fish_indent --ansi to format
the output of `builtin functions` for color output in `type`, etc.
We don't anymore.
Today it's not a potential showstopper if one launches a fish
session with a five year-old fish_indent in $PATH. We need not
go to lengths to try to make sure we run whatever is in the
build dir adjacent to the `fish` binary.
The 'str' variable was apparently mistakenly removed by 49c5f96470.
Re-add it, and regex-escape it as well.
Allow completing on apropos <TAB> instaed of requiring an initial char.
Use __fish_apropos instead of apropos.
New regex to hopefully work on more platforms.
Explicitly use ^ instead of adding it at __fish_apropos
For security reasons, some terminals require explicit permission from the
user to interpret OSC 52. One of them is [tmux] but that one usually runs
inside another terminal. This means we can usually write directly to the
underlying terminal, bypassing tmux and the need for user configuration.
This only works if the underlying terminal is writable to the fish user,
which may not be the case if we switched user. For this reason, keep writing
to stdout as well, which should work fine if tmux is configured correctly.
[tmux]: https://github.com/tmux/tmux/wiki/Clipboard
When running inside SSH, Control-X runs a clipboard utility on the remote
system. For pbcopy (and probably clip.exe too) this means that we write to the
remote system's clipboard. This is usually not what the user wants (although
it is consistent with fish_clipboard_paste). When X11 forwarding is used,
xclip/xsel copy to the SSH client's clipboard, which is what most users want.
When we don't have X11 forwarding, we need a different solution. Fortunately,
modern terminal emulators implement the OSC 52 escape sequence for setting
the clipboard of the terminal's system. Use it in fish_clipboard_copy.
Tested in SSH and Docker containers on foot, iTerm2, kitty, tmux and xterm
(this one requires "XTerm.vt100.allowWindowOps: true").
Should also work in GNU screen and Windows Terminal. On terminals that don't
support OSC 52 (like Gnome Terminal or Konsole), it seems to do nothing.
Since there does not seem to be a way to feature-probe OSC 52, let's just
always do both (pbcopy and friends as well as OSC 52). In future, we should
probably stop calling pbpaste and clip.exe, at least on remote systems.
I think there is also an escape sequence to request pasting the system
clipboard but that's less important and less popular, possibly due to
security concerns.
This makes the output a little easier on the eyes.
Tests appear to not need any changes to pass. I always forget whether or not
littlecheck cares about whitespace.
Two different bugs completely broke `trap -p`. First bug broke filtering of
functions with trap handlers (`functions -na` prints functions separated by a
comma, not a new line). Second bug broke showing of function definitions for
traps because a refactor renamed only some call sites but references to `$i`
renamed.
These issues were introduced in a6820cbe and appear to have been caught just in
time: no released version is affected (changes made post-3.5.1).
It's a variable that holds all potential directories. The old name
makes it confusing to look at some of its usage sites and figure out
what is actually going on because they make no sense if $dir is only one
entry.
Don't just save known color values but any values that could have been loaded
from a .theme file.
Also, refactor the theme variable name whitelist/filter in a shared "global"
variable so we never forget to update it at any of the individual use sites.
The documentation states that running `fish_config theme save` after
`fish_config theme choose [theme_name]` will result in "saving" the
currently chosen theme, but this does not match the actual behavior of
`fish_config theme save` which expects a trailing argument specifying
the name of the theme to select/persist.
Given that the documented way has been included in a release and that it
makes more sense than calling `fish_config theme save xxx` when you are
*loading from* xxx and not *saving to* xxx, this patch revises
`fish_config.fish` to support the documented behavior.
When `fish_config theme save xxx` is used, xxx is loaded w/ its specified colors
saved to the according variables in the universal scope. But if `fish_config
theme save` is used without a theme's name specified, then the currently
specified (known) fish color variables are persisted from whatever scope they're
currently in (usually in the global scope from previewing a theme) to universal
variables of the same name.
This does *not* catch color variables unknown to fish! If a theme and a
prompt agree on some variable to hold some color but it's not a color variable
known to fish, it won't be persisted!
Closes#9088.
This makes these tools usable in a pipe.
You can run
```fish
some-long-command | fish_clipboard_copy
```
to copy some command's output to your clipboard, and
```fish
fish_clipboard_paste | some-other-command
```
To feed your clipboard to some command.
We only erase existing globals for some of the theme-related variables
but not for all the `known_colors`, causing `fish_config` to still emit
warnings for these if saving a theme choice after trying it.
There are a million existing ways of skinning this cat, but it's a good parallel
to `__fish_seen_argument` to have, in a similar vein to
`__fish_seen_subcommand_from`.
Commit 09685c3682 tried making the apt
completions faster by doing two things:
1. Introduce a limiting "head"
2. Re-replace our "string" usage with tr
Unfortunately, in doing so it introduced a few issues:
1. The "tr" had a dangling "+" so it cut apart package
descriptions that contained a "+".
This caused e.g. "a C++ library" to generate another completion
candidate, "library".
2. In reusing "tr" it probably reintroduced #8575,
as tr is not 8-bit-clean.
3. It filtered too early, on the raw apt-cache output,
which caused it to fill up with long descriptions.
So e.g. for "texlive" it would only generate 10 completions,
where it should have matched 54 packages.
Because most of the speedup is in the "head" stopping early, we
instead go back to the old string way, but introduce a limiting "head"
after the "sed" (which will have removed everything but the package
name line and the first line of the description)
In my tests this is about ~10% slower than doing head early and using
tr, but it's more correct.
Admittedly I haven't been able to reproduce the 35s scenario that
09685 talks about, but the most likely cause of that is *apt-cache*
being slow - I don't see how string can be that much slower on another
system - and so it will most likely also be fixed by doing head here.
Future possibilities here include:
1. Using "apt-cache search --names-only", which gives a much nicer
format (but only for non-installed packages - the search strings are
apparently ANDed?)
2. Switching to `string split`, possibly using NUL and using `string
split0`?
3. Introducing a `string --null-in` switch so we can get by with one
`string`
4. (multi-threaded execution so the `string`s run in parallel)
`apt-cache` is just so incredibly slow that filtering against the final results
just doesn't cut it. Attempting to match against 'ac.*' (already taking
advantage of changing short search terms into prefix-only matches) would take
35 seconds, all of bottlenecked before the filtering step. This change uses more
of a heuristic to filter `apt-cache` results directly (before additional
filtering) to speed things up.
A variety of different limits from 100 to 5000 were timed and their result sets
compared to see what ended up artificially limiting valid completions vs what
took too long to be considered functional/usable and this is where we ended up.
* Replace ";" with "\n" in alias-generated functions
This can let us add a "#" in our aliases to make
them ignore additional arguments.
* Update changelog about aliases that ignore arguments
* Update test for alias.fish
This is now compliant with the aliases that can
ignore arguments.
This used a prompt command, but since the prompt was interpolated and
included a `?` it would be run as a glob without qmark-noglob.
Since it's simpler to pass a prompt string, just do that.
This checked the locale, but did so in a way that's fundamentally
broken:
1. $LANG isn't the only variable ($LC_ALL and $LC_CTYPE)
2. Even if $LANG is set that doesn't mean it's actually working
We could add a `status is-multibyte` here to figure out if we have a
multibyte locale?
But instead, since this is dealing with adding an ellipsis, let's just
add it to `string ellipsize`.
One slight difference is that shortening the branch now counts the ellipsis width.
I.e. assuming the branch is "long-branch-name"
```fish
set -g __fish_git_prompt_shorten_branch_len 8
```
might now print "long-br…" instead of "long-bra…". This is nicer because we can now give the actual maximum width.
The alternative is to add a "--exclusive" option to "string ellipsize" that doesn't count the ellipsis width. So `string ellipsize --char "..." --max 8" long-branch-name` might result in "long-bra...", which is 11 wide.
This moves the stuff that creates skeleton/boilerplate files to
the same place we initialize uvars for the first time or on upgrade.
Being a bit less aggresssive here theoretically makes launch a little
lighter but really I personally just found it weird I couldn't
just delete my empty config.fish file without it getting recreated
and sourced every launch.
This reimplements ridiculousfish/control_r which is a more future-proof
approach than #6686.
Pressing Control+R shows history in our pager and allows to search filter
commands with the pager search field.
On the surface, this works just like in other shells; though there are
some differences.
- Our pager shows multiple results at a time.
- Other shells allow to use up arrow/down arrow to select adjacent entries
in history. Shouldn't be hard to implement but the hidden state might
confuse users and it doesn't play well with up-or-search, so this is
left out.
Users might expect the history pager to use subsequence matching (fuzzy
matching) like the completion pager, however due to the history pager design it
uses substring matching. We could change this in future, however that means
we would also want to change the ordering from "reverse-chronological" to
"longest common subsequence" (e.g. what fuzzy finders do), because otherwise
a query "fis" might give this ordering:
fsck /dev/disk/by-partlabel/Linux\x20filesystem
fish
which is probably not what the user wants.
The pager shows only a small number of history items at a time. This is
because, as explained above, the history pager does not support subsequence
matching, so navigating it does not scale well.
Closes#602
This can be used to print the modification time, like `stat` with some
options.
The reason is that `stat` has caused us a number of portability
headaches:
1. It's not available everywhere by default
2. The versions are quite different
For instance, with GNU stat it's `stat -c '%Y'`, with macOS it's `stat
-f %m`.
So now checking a cache file can be done just with builtins.
/etc/hosts specifies, that everything after a #-character is to be
treated as a comment. The current __fish_print_hostnames however only
considers #-characters at the beginning of a line.
Thus the comment from following valid hosts-entry would end up in the
completion output:
1.2.3.4 myhost # examplecomment
getent hosts properly handles comments.
When we want to print something while the prompt is still active, we move the
cursor by printing a newline for each line in the prompt beyond the first
one. As established by 80fe0a7fc (fish_job_summary: Format message better
for multiline prompts, 2022-06-28), our use of "string repeat" actually
prints an extra newline. Let's remove it here as well.
This was supposed to be number of lines in the prompt minus 1, but
string repeat added one.
Also it triggered even in case of the stopped job message, which is
already repainted differently.
So we add it when we need to repaint ourselves.
As a bonus add a newline before in that case so the message isn't
awkwardly printed into the commandline.
Fixes#9044.
Discussions with the tmux maintainer show that:
1. We no longer need the passthrough sequence at all (and it's
deactivated by default)
2. Tmux can check if the outer terminal supports cursor shaping
Fixes#8981
This commit lets you check the manpage for a leading command by moving
the cursor over it, matching the behavior of tab complete.
It also lets you select the man page for the base of a two-part command
like `string match`.
The additional regex case is added because
`commandline -t` returns an empty string when the cursor is after a
space, e.g. at the end of 'sudo ', which the later checks don't handle.
This diagram shows the manpage picked for different cursor positions:
> sudo -Es time git commit -m foo
+-------++---++--++------------+
| || || || |
| || || |+------------+
| || || | git-commit
| || |+--+
| || | git
| |+---+
| | time
+-------+
sudo
* updated function __fish_print_portage_repository_paths.fish to support file, dir and modified defaults
* Revised version of share/functions/__fish_print_portage_repository_paths.fish
* improved syntax and regex as suggested
The recent improvements to multiline prompts and vi-mode in #3481 appear
to be sufficient to make iTerm2 well behaved, so remove our hack which
disabled it by default.
Fixes#3696
This removes the awkward secondary logic.
Note that we still ship a function called `__terlar_git_prompt`
because people who picked the prompt will still be calling it - we
don't update the prompt.
This makes it so
1. The informative status can work without showing untracked
files (previously it was disabled if bash.showUntrackedFiles was
false)
2. If untrackedfiles isn't explicitly enabled, we use -uno, so git
doesn't have to scan all the files.
In a large repository (like the FreeBSD ports repo), this can improve
performance by a factor of 5 or up.
Previously, `kill-whole-line` kills the line and its following
newline. This is insufficient when we are on the last line, because
it would not actually clear the line. The cursor would stay on the
line, which is not the correct behavior for bindings like `dd`.
Also, `cc` in vi-mode used `kill-whole-line`, which is not correct
because it should not remove any newlines. We have to introduce
another special input function (`kill-inner-line`) to fix this.
Arguments to --ignored were introduced in Git 2.16, from January 2018.
The git completions specifically work around this, allowing older
versions to be used; match this in the git prompt.
Fixes the tests on CentOS 7.
When switching this to use `git status`, I neglected to use the
correct definition of what a "dirty" and a "staged" change is.
So this now showed already staged files still as "dirty".
Fixes#8986
edit_command_buffer uses the "norm" command for moving the cursor to a column
with the "|" primitive. The problem is that the user can remap "|". Fix this
by using the "norm!" variant which ignores user mappings (see ":h norm").
Closes#8971
Previously, running `fish_add_path /foo /foo` would result in /foo
being added to $PATH twice.
Now we check that it hasn't already been given, so we skip the
second (and any further) occurence.
man-db's man 2.7 as shipped in OpenSUSE fails to set a non-zero
exit code when invoked like "man ls-some/dir". This means
that we fail to display the man page if the commandline is
"ls some/dir". Work around this by never treating tokens
with slashes as subcommand.
Pressing Ctrl-D while a command is running results in a null key code in
our input queue. That key code is bound to insert a space (without expanding
abbreviations). Make it only insert a space if the commandline is non-empty,
to accommodate this use case.
This probably affects other keys as well.
Closes#8871
As we've noticed a few times now, mingw/msys/cygwin has a fairly
horrible kill implementation that annoys us here.
However our workaround wasn't enough - "mingw" is also a name that is
used here and "msys" can also be a substring.
Also we need to silence the `kill` because it's better to not list the
signals than it is to spew errors.
Fixes#8915.
Some terminals can be configured to send variuos escape sequences for keys
that could historically not be detected. Turns out some usage pattern rely
on those quirks.
Shift+Space is easy to mistype when wanting to insert a space (especially
when typing ALL CAPS). Map it to Space, to match user expectations.
Similarly for Control+Return, for which xterm can be configured to send
something other than \cr:
echo 'XTerm.vt100.modifyOtherKeys: 1' | xrdb && xterm
I'm working on a change to builtin bind that allows to bind CSI sequences via
human-readable key names (#3018) but for now let's just map the raw sequences.
Closes#8874
micro only parses the [FILE]:LINE:COL syntax
if the parsecursor option is enabed
in the meanwhile, the +LINE:COL syntax is unambiguous and always valid
You can use an index with vared, like `vared PATH[4]`. However this was
inadverently broken in fa2450db30, because you cannot use `read` to
modify an element of a variable, only the whole variable. Fix this.
Unfortunately this means using another local variable, so we name it
__fish_vared_temp_value instead of just temp so that collisions are
unlikely.
* Print message in set_fish_path -v when a path doesnt exist
* Update changelog
* Remove "; or continue"
* use printf instead of echo, avoid localizing the path
As explained in the parent commit, if we print things to the command line,
we move the cursor down before redrawing a multi-line prompt. This is a
workaround to avoid erasing what we printed.
We forgot to do add this workaround to fish_job_summary. When running
`sleep 1 &` with a multiline prompt, the job exit notification is immediately
overwritten (most of the time). This can be observed consistently on Linux
by waiting before redrawing:
diff --git a/share/functions/fish_job_summary.fish b/share/functions/fish_job_summary.fish
index a552fabbc..f457ee8e8 100644
--- a/share/functions/fish_job_summary.fish
+++ b/share/functions/fish_job_summary.fish
@@ -52,6 +52,7 @@ function fish_job_summary -a job_id is_foreground cmd_line signal_or_end_name si
string repeat \n --count=(math (count (fish_prompt)) - 1) >&2
if test $is_foreground -eq 0; and test $signal_or_end_name != STOPPED
+ sleep 1
commandline -f repaint
end
end
Move the cursor down to work around this. In future, we could avoid calling
fish_prompt. Also, this solution add an extra blank lines before the next
prompt. With a real fix, we could get rid of that. Even worse, sometimes
there are two blank lines instead of one (for a two-line prompt).
Fixes#8817
We have some key bindings that print directly to the terminal while the user
is still typing the command line. Thereafter, we redraw the command line,
so the user can resume typing. To redraw a multiline command line, we first
erase several lines above the cursor. To not erase the key bindings' output,
we move the cursor down that many lines.
Simplify the logic; no functional change.
This conditionally set a function variable in an unsafe way.
If you do something like
```fish
if condition
set -f foo bar
end
```
then, if the condition was false, $foo could still use a global variable.
In this case, alias would now fail if a variable $wraps was defined globally.
This reverts most of commit 14458682d9.
The message rewording can stay, it's *fine* (tho it'll break the
translations but then we'd need a real string freeze with a
translation team for those to be worth anything anyway, soo)
