Some third party Git tools provide a man page, which we can at least use
for completing options.
The old logic excluded all generated completions for Git subcommands.
Instead, try to load completions for all available external subcommands.
We can use $PATH/git-* because /bin/git-add and friends were removed in Git
1.6.0 in 2008.
Closes#4358 (the "git-foo" wrapping was added in #7652)
Since #7075, git-foo.fish files are sourced when Git completions are loaded.
However, at least Cobra (CLI framework for Go) provides completions like
complete git-foo ...
This means that completions are only offered when typing "git-foo <TAB>"
and not on "git foo <TAB>". Fix this by forwarding the completion requests.
Take care to only forward if there are actually completions for "git-foo",
to avoid adding filename completions.
It also reflows.
We might want to think about doing something more extensible here, as
konsole is also about to add reflow, but for now the main problem
children here are VTE and alacritty.
Extends #7491.
Prior to this change, a glob like `**/file.txt` would only match
`file.txt` in subdirectories; the `**` must match at least one directory.
This is historical behavior.
With this change we move a little closer to bash's implementation by
allowing a literal `**` segment to match in the current directory. That
is, `**/foo` will match both `foo` and `bar/foo`, while `b**/foo` will
only match `bar/foo`.
Fixes#7222.
Prior to this change, if fish were launched connected to a tty but not as
pgroup leader, it would attempt to become pgroup leader only if
--interactive is explicitly passed. But bash will unconditionally attempt
to become pgroup leader if launched interactively. This can result in
scenarios where fish is running interactively but in another pgroup. The
most obvious impact is that control-C will result in the pgroup leader
(not fish) exiting and make fish orphaned.
Switch to matching the bash behavior here - we will always try to become
pgroup leader if interactive.
Fixes#7060.
"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
When fish presents an autosuggestion, there is some logic around whether
to retain it or discard it as the user types "into" it. Prior to this
change, we would retain the autosuggestion if the user's input text is a
case-insensitive prefix of the autosuggestion. This is reasonable for
certain case-insensitive autosuggestions like files, but it is confusing
especially for history items, e.g. `git branch -d ...` and `git branch -D
...` should not be considered a match.
With this change, when we compute the autosuggestion we record whether it
is "icase", and that controls whether the autosuggestion permits a
case-insensitive extension.
This addresses part of #3978.
