This added a space if only one character was added, e.g.
```fish
cd dev<TAB>
```
would complete to
```fish
cd dev/<SPACE>
```
which makes picking deeper directories awkward.
So just go back to the old behavior of doing it for any length.
This is a regression from e27d97b02e.
cc @krobelus
Prior to this change, histories were immortal and allocated with either
unique_ptr or just leaked via new. But this can result in races in the
path detection test, as the destructor races with the pointer-captured
history. Switch to using shared_ptr.
If the user types something like `/**`, prior to this change we would
attempt to expand it in the background for both highlighting and
autosuggestions. This could thrash your disk and also consume a lot of
memory.
Add a a field to operation_context_t to allow specifying a limit, and add
a "default background" limit of 512 items.
When a completion's "--arguments" script ran, it would clobber $status with its value,
so when you repainted your prompt, it would now show the completion
script's status rather than the status of what you last ran.
Solve this by just storing the status and restoring it - other places
do this by calling exec_subshell with apply_exit_status set to false,
which does basically the same thing. We can't use it here because we
don't want to run a "full" script, we only want the arguments to be
expanded, without a "real" command.
No, I have no idea how to test this automatically.
Fixes#7555.
And again clang-format does something I don't like:
- if (found != end && std::strncmp(found->name, name, len) == 0 && found->name[len] == 0) return found;
+ if (found != end && std::strncmp(found->name, name, len) == 0 && found->name[len] == 0)
+ return found;
I *know* this is a bit of a long line. I would still quite like having
no brace-less multi-line if *ever*. Either put the body on the same
line, or add braces.
Blergh
This adds the ability to limit how many expansions are produced. For
example if $big contains 10 items, and is Cartesian-expanded as
$big$big$big$big... 10 times, we would naviely get 10^10 = 10 billion
results, which fish can't actually handle. Implement this in
completion_receiver_t, which now can return false to indicate an overflow.
The initial expansion limit 'k_default_expansion_limit' is set as 512k
items. There's no way for users to change this at present.
This switches certain uses from just appending to a list to using
completion_receiver_t, in preparation for limiting how many completions
may be produced. Perhaps in time this could also be used for "streaming"
completions.
completion_receiver_t wraps a completion list; it will centralize logic
around adding completions and most importantly it will enforce that we
do not exceed our expansion limit.
"smartcase" performs case-insensitive matching if the input string is all
lowercase, and case-sensitive matching otherwise. When completing e.g.
files, we will now show both case sensitive and insensitive completions if
the input string does not contain uppercase characters.
This is a delicate fix in an interactive component with low test coverage.
It's likely something will regress here.
Fixes#3978
In preparation for introducing "smart case", refactor string fuzzy
matching. Specifically split out the case folding and match type into
separate fields, so that we can introduce more case folding types without
a combinatoric explosion.
`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.
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.
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.
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.
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.
Currently only `complete` will list completions, and it will list all
of them.
That's a bit ridiculous, especially since `complete -c foo` just does nothing.
So just make `complete -c foo` list all the completions for `foo`.
Found with gcc's -Wmissing-declarations which gives warnings like
../src/tinyexpr.cpp:61:5: warning: no previous declaration for ‘int get_arity(int)’ [-Wmissing-declarations]
61 | int get_arity(const int type) {
The same warnings show up for builtin functions like builtin_bg because they
currently don't include their own headers. I left that.
Also reformat the touched files.
For the last 15 years the space was only skipped when the completion
ended in one of "/=@:". Add ".," since they are also sometimes used to
separate independent words within a token.
Fixes#6928
Improves on #6833
Use some more move semantics to reduce allocations.
Correctly handle the case where the completion is empty. For example, if
you type:
ls<tab>
we get an empty completion (since ls is already a valid command), but we
still want to show its description.
Remove some unsafe statics - these are unsafe today in weird cases where
completions might invoke complete recursively, and also will soon be
unsafe with concurrent execution.
