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.
The "wrap chain" refers to a sequence of commands which wrap other
commands, for completion purposes. One possibility is that a wrap chain
will produce a combinatorial explosion or even an infinite loop, so there
needs to be logic to prevent that. Part of that logic is encapsulated in a
visited set (wrap_chain_visited_set_t) to prevent exploring the same item
twice.
Prior to this change, we stored pairs (command, wrapped_command). But we
only really need to store the wrapped command. Switch to that.
One consequence is that if a command wraps another command in more than
one way, we won't explore both ways. This seems unlikely in practice.
Detect recursive calls to builtin complete and the internal completion in
the same place.
In 0a0149cc2 (Prevent infinite recursion when completion wraps variable assignment)
we don't print an error when completing certain aliases like:
alias vim "A=B vim"
But we also gave no completions.
We could make this case work, but I think that trying to salvage situations
like this one is way too complex. Instead, let the user know by printing an
error. Not sure if the style of the error fits.
We could add some heuristic to alias to not add --wraps in some cyclic cases.
The lambda has grown way too big, and it was not easy to see what the inputs
and outputs are. We always use the same visitor, so the function parameter
is not necessary.
This reads any additional positional arguments given to `fish -c` into
$argv.
We don't handle the first argument specially (as `$0`) as that's confusing and
doesn't seem very useful.
Fixes#2314.
This allows
bind -k backspace suppress-autosuggestion or backward-delete-char
To remove the suggestion on the first press and then delete
chars.
Note: This requires that we then don't reenable suggestions
immediately afterwards. Currently we don't after deletion.
Fixes#1419.
../CHANGELOG.rst:30: WARNING: Bullet list ends without a blank line; unexpected unindent.
../CHANGELOG.rst:117: WARNING: Inline literal start-string without end-string.
[ci skip]
This was a wrapper around status_to_signal, just because that only
handled a single argument.
Instead, just teach status_to_signal to handle multiple arguments and
be done.
Try to keep related things together - first the variable questions,
then the prompt questions, then more customization, then syntax
incompatibilities, ...
I'm not convinced all of these are actually frequently asked, or that
all frequently asked questions are here, but that's for later.
[ci skip]
This makes history searches case-insensitive, unless the search string
contains an uppercase character.
This is what vim calls "smartcase".
Fixes#7273.
Closes#7344
Apply a targeted fix to the place where complete() is called to handle nested
variable assignments. Sadly, reporting an error is probably not okay here,
because people might legitimately use aliases like:
alias vim "A=B command vim"
This is all a bit ugly, and I hope to find a cleaner solution. Supporting
completions on commandlines like `x=$PWD cd $x/ ` is a nice feature but it
comes with some complexity.
This is too important to not be one.
For one if it couldn't be loaded for any reason it would
break a lot of fish scripts.
Also this is faster by ~20x.
Fixes#7342
4f0ade7a73 broke the tests when LANG was
C, so the MB_CUR_MAX==1 path wasn't working.
Seemingly that cast is doing some work here?
Just revert that bit for now, since this path is unimportant
anyway (please, please, please, please use a unicode capable locale).
