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
git had a CVE related to arbitrary code being run when you run git status and similar, and instead of doing something about those arbitrary code bits they decided to lock it down entirely.
So now git will refuse to do basically anything once it detects the .git directory is owned by someone else.
So, what we do is:
If `git describe` failed with a status of 128, we keep an already
built version file.
This is an awful hack, but should help with the normal `cmake; make; sudo
make install` cycle.
(the only *real* way around this seems to be to not attempt to rebuild
the version file at install time entirely, but I have no idea how to
do that)
Fixes#8973.
With sphinx 4.5.0:
1. Some of our builtins actually give results (cd, end, set)
2. Some give broken results (and, if, or)
3. Only "for" even triggers the help page we hacked in
So this is of dubious use, and removing it gets us out of the awkward situation of shipping it.
Plus upstream sphinx has ditched jquery, so we would have to rewrite it anyway.
Like `set` and `read` before it, `eval` can be used to set variables,
and so it can't be shadowed by a function without loss of
functionality.
So this forbids it.
Incidentally, this means we will no longer try to autoload an
`eval.fish` file that's left over from an old version, which would
have helped with #8963.
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.
[ 97%] Building man pages with Sphinx
../CHANGELOG.rst:123: WARNING: Bullet list ends without a blank line; unexpected unindent.
[ 97%] Built target sphinx-manpages
[ 98%] Building HTML documentation with Sphinx
../CHANGELOG.rst:123: WARNING: Bullet list ends without a blank line; unexpected unindent.
This concerns what happens if one event handler removes another, when
both are responding to the same event. Previously we had a "double lock"
where we would traverse the list twice. Now track directly in the
handler when it is removed; this simplifies the code a lot. No
functional changes expected here.
Hitting tab on "echo **" will often result in more than 256 matches.
Commit 143757e8c (Expand wildcards on tab, 2021-11-27) describes this scenario
> If the expansion would produce more than 256 items, we flash the command
> line and do nothing, since it would make the commandline overfull.
Yet we actually erase the "**" token, which seems wrong since we already
flash the command line. Fix this, at the cost of making the code a bit uglier.
I tried to write a test in tests/pexpects/wildcard_tab.py but that doesn't
seem to work because pexpect provides only a "dumb" terminal. I wonder if we
can test what we write to the screen without depending on a terminal emulator.
`wg show` command shows entire interfaces configuration, not just the
list. This breaks completion when running fish from root, because
command output looks like this:
interface: wg0
public key: fred2rX85AxpcTObLuiWTzkRPZaXjnhd1C4XOdZOGWs=
private key: (hidden)
listening port: 12345
fwmark: 0xca6c
peer: g2YHHDkxmgoT9EV0TxKtq556WLXpaOh4zgC5L7EAGTQ=
endpoint: 192.168.88.50:54321
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 1 minute, 37 seconds ago
transfer: 1.83 MiB received, 927.19 KiB sent
To show just the list of active interfaces, `wg show interfaces` should
be used instead.
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.
Because TAGs are easy to type and complete, but commits with its SHA are
difficult to complete manualy. Keep commits and TAGs order to show more recent
commits first.
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
c4fb857dac (in 3.4.1) introduced a regression where process_exit
events would only fire once the job itself is complete. Allow
process_exit events to fire before that. Fixes#8914.
This is after we've tried to find the interpreter, so we would already
have complained about e.g. /usr/bin/pthyon not existing.
Realistically the most common case here is things that don't start
with a shebang like ELFs. Writing special extraction code here is
overkill, and I can't see a good function to do it for us.
But this should point you in the right direction.
Fixes#8938
This gets the passwd entry for $USER (if it is set). If that gives the
same uid that geteuid() gives us, we assume the data is correct.
If not, we reset $USER (and $HOME if it's empty) from the passwd value for our UID.
This allows using $USER in a prompt even if you've `su`d. Bash gets around this by having a special escape in its $PS1 DSL that checks passwd instead.
Fixes#8583
Whenever completing any git commandline, we invoke __fish_git_using_command
173 times*. Every invocation calls "commandline" and "argparse"
to the same effect. Let's parse the command line once, and reuse the results
later.
I'm observing a speed-up from 200ms to 120ms with
perf stat -r 10 buildrel/fish -c 'complete -C "git checkout ">/dev/null'
Alternative solutions:
1. teach fish to cache such things automatically.
2. rewrite git completions to compute most completions in a single function,
which will naturally avoid redundant work. This sounds viable but it's
a lot of work.
* we have a thousand uses of __fish_git_using_command, so I'm not sure why
it's only 173.
See the discussion in #8266
