It may happen that the user types an abbreviation and then hits return.
Prior to this commit, we would perform a form of syntax highlighting
that does not require I/O, so as to not block the user. However this
could cause invalid commands to be colored as valid.
More generally if the user has e.g a slow NFS mount, then syntax
highlighting may lag behind the user's typing, and be incorrect at the
time the user hits return. This is an unavoidable race, since proper
syntax highlighting may take arbitrarily long.
Introduce a new function `finish_highlighting_before_exec`, which waits
for any outstanding syntax highlighting to complete, BUT has a timeout
(250 milliseconds). After this, it falls back to the no-I/O variant, which
colors all commands as valid and nothing as paths.
Fixes#7418Fixes#5912
In some cases the completion we come up with may be unexpected, e.g.
if you have files like
/etc/realfile
and
/etc/wrongfile
and enter "/etc/gile", it will accept "wrongfile" because "g" and
"ile" are in there - it's a substring insertion match.
The underlying cause was a typo, so it should be easy to go back.
So we do a bit of magic and let "cancel" undo, but only right after a
completion was accepted via complete or complete-and-search.
That means that just reflexively pressing escape would, by default, get you back to
the old token and let you fix your mistake.
We don't do this when the completion was accepted via the pager,
because 1. there's more of a chance to see the problem there and 2.
it's harder to redo in that case.
Fixes#7433.
This was typically overridden by "too many/few arguments", but it's
actually incorrect:
sin(55
has the correct number of arguments to `sin`, but it's lacking
the closing `)`.
fish_user_paths is a fish-specific variable that can be persisted by
making it a universal variable or by making it a global variable set at
startup in `config.fish`.
Since it is not defined in a clean installation, a user could
inadvertently create it as `set -Ux fish_user_paths ....` the first
time, creating a horrible, ugly, self-loathing mess that will have you
chasing ghosts and bisecting for naught once fish re-imports
fish_user_paths as a *global* variable that shadows the universal one.
While that is true for any universal variable that is re-imported as a
global variable, only fish_user_paths has the potential to really screw
things up because we also re-export PATH based off of its value in turn.
This fixes up the SIGIO notifier in preparation for using it on BSD. It
removes the reliance on the signal's si_code, which is not available in
BSD, and it properly handles the BSD behavior where SIGIO is delivered on
a read even if the read returns EAGAIN.
Fix an error caused by `exec_job()` assuming a job launched with the
intention of being backgrounded would have a pgid assigned in all cases,
without considering the status of `exec_error` which could have resulted
in the job failing before it was launched into its own process group.
Fixes (but doesn't close) #7423 - that can be closed if this assertion
failure doesn't happen in any released fish versions.
It is apparently possible to launch fish such that its pid owns the tty,
but its pid is in a different pgroup. In that case, do not attempt to stop
with SIGTTIN; instead simply attempt to place fish in its own pgroup.
Fixes#7388
`complete_param_expand` knows how to handle cases like `foo=br` so we
don't need to bother sending just the `br` part. Furthermore, sending
just `br` is incorrect because we will end up replacing the entirety of
`foo=br` with the result of the completion. That is, `foo=br` will be
replaced with `bar` instead of being completed to `foo=bar`.
This switch is no longer necessary when only one command is given.
Internally completions are stored separately for each command,
so we only every print one command name per "complete" line anyway.
On WSL1, fcntl(F_SETOWN) will fail and this would report an error.
Suppress this error message since it is not very interesting.
The effect is to disable real-time universal variable propagation.
Introduce a new strategy for notifying other fish processes of universal
variable changes, as a planned replacement for the complex
strategy_named_pipe. The new strategy still uses a named pipe, but instead
of select() on it, it arranges for SIGIO to be delivered when data is
available. If a SIGIO has been seen since the last check, it means the file
needs to be re-read.
When expanding a string, you may or may not want to generate
descriptions alongside the expanded string. Usually you don't want to
but descriptions were opt out. This commit makes them opt in.
If the padding is not divisible by the char's width without remainder,
we pad the remainder with spaces, so the total width of the output is correct.
Also add completions, changelog entry, adjust documentation, add examples
with emoji and some tests. Apply some minor style nitpicks and avoid extra
allocations of the input strings.
Improves on #7328.
I believe this is the correct behavior, simply skip all whitespace before
a word. Try with
./fish -C 'bind \ef forward-bigword; bind \eb backward-bigword; bind \ed kill-bigword; bind \cw backward-kill-bigword'
Also unrelated formatting fixes. I don't think a CI failure on unformatted
code is warranted but I wish it could do that behind the scenes.
For example "grep --color"<TAB> can complete to "grep --color=". Don't add
a space in this case; we do the same for arguments that end in =.
In GNU-style getopt, equal sign means that the flag has an argument. Without
the = it would not consume the next argument as opposed to Python's argparse.
This was a weird special behavior where we'd put the commandline on a
new line if it wrapped *and* the prompt was > 33% of the screen.
It seems to be more confusing than anything.
Fixes#5118.
Prior to this change, tab completing with a variable assignment like
`VAR=val cmd<tab>` would parse out and apply VAR=val, then recursively
invoke completions. This caused some awkwardness around the wrap chain -
if a wrapped command had a variable completion we risked infinite
recursion. A secondary problem is that we would run any command
substitutions inside variable assignment, which the user does not expect
to run until pressing enter.
With this change, we explicitly track variable assignments encountered
during tab completion, including both those explicitly given on the
command line and those found during wrap chain walk. We then apply them
while suppressing command substitutions.
In preparation for applying variable assignments (VAR=VAL cmd), separate
them out from the command when performing completions. This includes both
those that the user typed, and any that come about through
completion --wraps.
When completing and walking a wrap chain, we pass around a lot of
information. Factor this together into a new struct custom_arg_data_t
which reduces the number of parameters needed.
