The \e\e\[A style is bad but iTerm and putty (alt-left) use it.
The main motivation for this change is to improve fish_key_reader output.
Part of #10663
Both are plenty fast enough, but this way the output of fish_trace isn't
completely taken over by the loops (seems fair since fish_trace probably gets
used rather heavily for completions).
Part of #1842
The implementation is obviously isn't 100% vi compatible, but works good enough
for major cases
This commit depends on previous commits where jump-{to, till}-matching-bracket
motions were introduces
One issue with fish_add_path at the moment is that it is sometimes a bit too intransparent.
You'll try to add a path, but it won't appear - was that because it wasn't a directory,
or because it doesn't exist, or because it was already included?
If it isn't usable after, did fish_add_path not add it because of something or did something *else* remove it?
So we give more explanations - "skipping this because it's a file", "not setting anything because no paths are left to add", ...
fish_add_path can be used either interactively, in the commandline,
or in config.fish. That's its greatest strength, it's a very
DWIM-style command.
One of the compromises that entails, however, is that it can't really
be very loud about what it does. If it skips a path, it can't write a
warning because it might be used in config.fish.
But it *can* if it's used interactively. So we try to detect that case
and enable verbose mode automatically.
That means if you do
```fish
fish_add_path /opt/mytool/bin/mytool
```
it may tell you "Skipping path because it is a file instead of a
directory:".
The check isn't perfect, it goes through status current-command and
isatty, but it should be good for most cases (and be false in config.fish).
Don't fork/exec an external process, especially one performing IO, if we don't
have to.
This, in turn, speeds up __fish_source_cached_completions which is rather slow
under WSL (and slower than it needs to be on other platforms).
We don't set this variable ourselves, but some might set it in their config out
of habit coming from shells that don't automatically colorize ls output.
This variable overrides stdout tty detection for `ls --color=auto` (but does not
modify the behavior of `ls --color=never` or `ls --color=always` regardless of
its value) under at least the BSD version of `ls`. (Under the GNU version, it
influences colorization only if stdout *is* a tty.)
If we detect CLICOLOR_FORCE *and* we are not writing directly to the tty, we
skip colorization (by clearing-but-not-erasing `$__fish_ls_color_opt`, so that
we don't end up accidentally using its value from another scope).
c0bcd817ba removed some key bindings, including the bindings of
ESC ESC [ C for Alt-Right. the commit claimed that
"Sequences like \e\eOC are Escape followed by an SS3 arrow key which we
can already decode separately." but for whatever reason this doesn't work:
Alt-Right is broken in iTerm2 by default.
Restore the default ESC ESC [ X bindings for iTerm2 compatibility.
I've been needing this for some time to generate completions for functions that
we can dynamically generate completions for that take one or more
comma-separated values in any order.
We ignore typed control characters 33a7172ee (Revert to not inserting control
characters from keyboard input, 2024-03-02).
We used to do the same for bracketed paste but that changed in 8bf8b10f6
(Extended & human-friendly keys, 2024-03-30) which made bracketed paste
behave like fish_clipboard_paste; it inserts the exact input (minus leading
whitespace etc). At that time it wasn't clear to me which behavior was the
right one (because of the inconsistency between terminal and bracketed paste).
As reported in
https://matrix.to/#/!YLTeaulxSDauOOxBoR:matrix.org/$PEEOAoyJY-644amIio0CWmq1TkpEDdSy2QnfJdK-dco
trailing tabs in pasted text can be confusing.
There seems to be not real need to insert raw control characters into the
command line, so let's strip them when pasting.
Now the only way to insert a raw control character into the command line is
to recall it from command history. Not sure what the behavior should be for
that case, we can revisit that later. If we get rid of raw control characters
entirely, then we can also delete the new "control pictures" rendering :)
Given "abbr foo something", the input sequence
foo<space><ctrl-z><space>
would re-expand the abbreviation on the second space which is surprising
because the cursor is not at or inside the command token. This looks to be
a regression from 00432df42 (Trigger abbreviations after inserting process
separators, 2024-04-13)
Happily, 69583f303 (Allow restricting abbreviations to specific commands
(#10452), 2024-04-24) made some changes that mean the bad commit seems no
longer necessary. Not sure why it works but I'll take it.
In addition to the native Emacs undo binding, we also support ctrl-z.
On Linux, ctrl-shift-z alias ctrl-Z is the redo binding according to
https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts Let's bind allow
that.
Unfortunately ctrl-shift and ctrl-alt modified shortcuts on Linux may be
intercepted by the windowing system or the terminal. Only alt-shift seems to be
available reliably (but the shift bit should mean "extend selection" in Emacs).
iTerm2 supports CSI u so the custom bindings are no longer needed. Sequences
like \e\eOC are Escape followed by an SS3 arrow key which we can already
decode separately.
In ImageMagick 7 or later, legacy commands have been replaced with
magick. Here a new functions, defines these completions and it is
called for `magick` and `magick convert`.
fixes#7172. Closes#10307.
Co-authored-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
We were inconsistent about this for no apparent reason.
Also cleaning up in ~/.config/fish/completions is
irrelevant by now since we moved to ~/.local/share/fish 8 years ago.
Now that the parent commit moved it again, cleaning up that one seems
reasonable.
wl-copy is a daemon process that serves its stdin to any wl-paste processes.
On Wayland, we launch it from fish_clipboard_copy. It then lives in the
same process group as fish (see `ps -o pid,pgid,comm`).
For some reason pressing ctrl-c inside the VSCode integrated terminal with
fish as the default shell kills the wl-copy process, thus clearing the
clipboard. On other terminals it works fine.
This is also reproducible by running "echo foo | wl-copy" ctrl-v ctrl-c ctrl-v
(the second ctrl-v does not paste because wl-copy was killed).
Work around this for now by running wl-copy asynchronously, and disowning it.
This seems to fix it though I really don't know why. Alternatively we could
"setsid" but that's technically not available on BSD.
For some reason this works in Bash. We should strace it to figure out why.
alt-d used to do that until evil merge[*] 213e90704 (Merge remote-tracking branch
'upstream/master' into bind_mode, 2014-01-15) which changed the order of
the \ed bindings such that the smart dirh version would be shadowed by the
simpler ones.
[*] git blame alone failed to find it because it skips merge commits.
This is another problem that has been bothering me for years: as mentioned
in 1dd901e52 (Maintain cursor in history prefix search, 2024-04-12), up-arrow
search highlights search matches but the contrast is really bad, especially in
command position, because the search matches --background=brblack is combined
with whatever foreground syntax highlighting the command has. The history
pager had a similar problem (for the selected history item) but circumented
it by disabling syntax highlighting altogether for the selected item.
fish_color_search_match's foreground component is ignored.
Let's use it instead of syntax highlighting.
This fixes the contrast on some default colorschemes but the bryellow
foreground looks weirdly like an error/warning on some terminals. Change it
to white. This needs a hack because we don't have a canonical way to tell
if a uvar has been set by the user. Fortunately the foreground component
hasn't been used at all so far, so we're not so much changing it as much as
initializing it.
Indented multiline commandlines look ugly in an external editor. Also,
fish doesn't properly handle the case when the editor runs fish_indent.
Fix is by indenting when exporting the commandline and un-indenting when
importing the commandline again.
Unindent only if the file is properly indented (meaning at least by the
amount fish would use). Another complication is that we need to offset
cursor positions by the indentation.
This approach exposes "fish_indent --only-indent" and "--only-unindent"
though I don't imagine they are useful for others so I'm not sure if this
is the right place and whether we should even document it.
One alternative is to add "commandline --indented" to handle indentation
transparently.
So "commandline --indented" would print a indented lines,
and "commandline --indented 'if true' ' echo'" would remove the unecessary
indentation before replacing the commandline.
That would probably simplify the logic for the cursor position offset.
