github-mirror/fish-shell
2
0
Fork 0
mirror of https://github.com/fish-shell/fish-shell.git synced 2024-11-28 12:13:55 +08:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
fb99edae92
fish-shell/tests/checks/complete.fish

606 lines
19 KiB
Fish
Raw Normal View History

tests: filter control sequences only when interactive This demonstrates that we only write control sequences when interactive.
2024-04-12 18:19:32 +08:00
#RUN: %fish -C 'set -l fish %fish' %s
Run fish_indent on all our fish scripts It's now good enough to do so. We don't allow grid-alignment: ```fish complete -c foo -s b -l barnanana -a '(something)' complete -c foo -s z -a '(something)' ``` becomes ```fish complete -c foo -s b -l barnanana -a '(something)' complete -c foo -s z -a '(something)' ``` It's just more trouble than it is worth. The one part I'd change: We align and/or'd parts of an if-condition with the in-block code: ```fish if true and false dosomething end ``` becomes ```fish if true and false dosomething end ``` but it's not used terribly much and if we ever fix it we can just reindent.
2020-01-14 03:34:22 +08:00
function complete_test_alpha1
echo $argv
end
Teach alias about wrap argument injection Update the alias function to pass arguments to 'wraps'. For example alias gco='git checkout' now works like it ought to.
2018-02-28 06:06:39 +08:00
Wrapping completions to allow injecting arguments This enables some limited use of arguments for wrapping completions. The simplest example is that complete gco -w 'git checkout' now works like you would want: `gco <tab>` now invokes git's completions with the `checkout` argument prepended. Fixes #1976
2018-02-27 11:21:46 +08:00
complete -c complete_test_alpha1 --no-files -a '(commandline)'
complete -c complete_test_alpha2 --no-files -w 'complete_test_alpha1 extra1'
complete -c complete_test_alpha3 --no-files -w 'complete_test_alpha2 extra2'
complete -C'complete_test_alpha1 arg1 '
Fix complete.fish test It depends on `mktemp -d TAG` returning a relative path, which isn't guaranteed to be the case (and isn't the case when run by our test driver).
2021-03-23 15:12:06 +08:00
# CHECK: complete_test_alpha1 arg1
Add --escape option to `complete -C` An example use case is an external completion pager: bind \cg "commandline -rt (complete -C --escape|fzf|cut -d\t -f1)\ " Fixes #3469
2022-01-15 22:57:29 +08:00
complete --escape -C'complete_test_alpha1 arg1 '
Insert some completions with quotes instead of backslashes File names that have lots of spaces look quite ugly when inserted as completions because every space will have a backslash. Add an initial heuristic to decide when to use quotes instead of backslash escapes. Quote when 1. it's not an autosuggestion 2. we replace the token or insert a fresh one 3. we will add a space at the end In future we could relax some of these requirements. Requirement 2 means we don't quote when appending to an existing token. Need to find a natural behavior here. Re 3, if the completion adds no space, users will probably want to add more characters, which looks a bit weird if the token has a trailing quote. We could relax this requirement for directory completions, so «ls so» completes to «ls 'some dir with spaces'/». Closes #5433
2024-04-13 07:59:07 +08:00
# CHECK: 'complete_test_alpha1 arg1 '
Wrapping completions to allow injecting arguments This enables some limited use of arguments for wrapping completions. The simplest example is that complete gco -w 'git checkout' now works like you would want: `gco <tab>` now invokes git's completions with the `checkout` argument prepended. Fixes #1976
2018-02-27 11:21:46 +08:00
complete -C'complete_test_alpha2 arg2 '
Fix complete.fish test It depends on `mktemp -d TAG` returning a relative path, which isn't guaranteed to be the case (and isn't the case when run by our test driver).
2021-03-23 15:12:06 +08:00
# CHECK: complete_test_alpha1 extra1 arg2
Wrapping completions to allow injecting arguments This enables some limited use of arguments for wrapping completions. The simplest example is that complete gco -w 'git checkout' now works like you would want: `gco <tab>` now invokes git's completions with the `checkout` argument prepended. Fixes #1976
2018-02-27 11:21:46 +08:00
complete -C'complete_test_alpha3 arg3 '
Fix complete.fish test It depends on `mktemp -d TAG` returning a relative path, which isn't guaranteed to be the case (and isn't the case when run by our test driver).
2021-03-23 15:12:06 +08:00
# CHECK: complete_test_alpha1 extra1 extra2 arg3
builtin_complete: Allow `complete -C something` This is a long-standing issue with how `complete --do-complete` does its argument parsing: It takes an optional argument, so it has to be attached to the token like `complete --do-complete=foo` or (worse) `complete -Cfoo`. But since `complete` doesn't take any bare arguments otherwise (it would error with "too many arguments" if you did `complete -C foo`) we can just take one free argument as the argument to `--do-complete`. It's more of a command than an option anyway, since it entirely changes what the `complete` call _does_.
2019-04-26 20:54:51 +08:00
# Works even with the argument as a separate token.
complete -C 'complete_test_alpha3 arg3 '
Fix complete.fish test It depends on `mktemp -d TAG` returning a relative path, which isn't guaranteed to be the case (and isn't the case when run by our test driver).
2021-03-23 15:12:06 +08:00
# CHECK: complete_test_alpha1 extra1 extra2 arg3
Teach alias about wrap argument injection Update the alias function to pass arguments to 'wraps'. For example alias gco='git checkout' now works like it ought to.
2018-02-28 06:06:39 +08:00
alias myalias1 'complete_test_alpha1 arg1'
alias myalias2='complete_test_alpha1 arg2'
myalias1 call1
myalias2 call2
Port complete tests to littlecheck
2019-07-03 18:57:23 +08:00
# CHECK: arg1 call1
# CHECK: arg2 call2
Teach alias about wrap argument injection Update the alias function to pass arguments to 'wraps'. For example alias gco='git checkout' now works like it ought to.
2018-02-28 06:06:39 +08:00
complete -C'myalias1 call3 '
Test that things can't wrap themselves This is a test belonging to the previous commit, 58b696bed. See #5541.
2019-01-17 23:43:24 +08:00
complete -C'myalias2 call3 '
Fix complete.fish test It depends on `mktemp -d TAG` returning a relative path, which isn't guaranteed to be the case (and isn't the case when run by our test driver).
2021-03-23 15:12:06 +08:00
# CHECK: complete_test_alpha1 arg1 call3
# CHECK: complete_test_alpha1 arg2 call3
Test that things can't wrap themselves This is a test belonging to the previous commit, 58b696bed. See #5541.
2019-01-17 23:43:24 +08:00
# Ensure that commands can't wrap themselves - if this did,
# the completion would be executed a bunch of times.
Run fish_indent on all our fish scripts It's now good enough to do so. We don't allow grid-alignment: ```fish complete -c foo -s b -l barnanana -a '(something)' complete -c foo -s z -a '(something)' ``` becomes ```fish complete -c foo -s b -l barnanana -a '(something)' complete -c foo -s z -a '(something)' ``` It's just more trouble than it is worth. The one part I'd change: We align and/or'd parts of an if-condition with the in-block code: ```fish if true and false dosomething end ``` becomes ```fish if true and false dosomething end ``` but it's not used terribly much and if we ever fix it we can just reindent.
2020-01-14 03:34:22 +08:00
function t --wraps t
echo t
end
Test that things can't wrap themselves This is a test belonging to the previous commit, 58b696bed. See #5541.
2019-01-17 23:43:24 +08:00
complete -c t -fa '(t)'
complete -C't '
Port complete tests to littlecheck
2019-07-03 18:57:23 +08:00
# CHECK: t
complete: Add "--force-files" This allows a completion to specify that *it* takes files. Useful for things like `sudo -e`, because sudo usually doesn't take any files.
2019-05-31 01:12:49 +08:00
# Ensure file completion happens even though it was disabled above.
complete -c t -l fileoption -rF
Port complete tests to littlecheck
2019-07-03 18:57:23 +08:00
# Only match one file because I don't want to touch this any time we add a test file.
Remove redundant expect tests With the new pexpect based framework, bind and pipeline expect tests can be removed. Amusingly the complete.fish check required the existence of bind.expect. Fix the check at the same time.
2020-03-22 08:46:56 +08:00
complete -C't --fileoption ' | string match test.fish
# CHECK: test.fish
Add tests for `complete` (no args) output Hopefully this should catch things if the output gets broken again.
2019-09-20 06:01:09 +08:00
__fish_complete_directories: Use an empty command as the dummy Fixes #9574
2023-02-15 00:06:11 +08:00
# See that an empty command gets files
complete -C'"" t' | string match test.fish
# CHECK: test.fish
Add tests for `complete` (no args) output Hopefully this should catch things if the output gets broken again.
2019-09-20 06:01:09 +08:00
# Make sure bare `complete` is reasonable,
complete -p '/complete test/beta1' -d 'desc, desc' -sZ
complete -c 'complete test beta2' -r -d 'desc \' desc2 [' -a 'foo bar'
Reindent functions to remove useless quotes This does not include checks/function.fish because that currently includes a "; end" in a message that indent would remove, breaking the test.
2020-03-10 02:36:12 +08:00
complete -c complete_test_beta2 -x -n false -A -o test
Add tests for `complete` (no args) output Hopefully this should catch things if the output gets broken again.
2019-09-20 06:01:09 +08:00
complete
complete: print completions without the implied `-c` switch 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.
2020-10-10 17:54:52 +08:00
# CHECK: complete --no-files complete_test_alpha1 -a '(commandline)'
# CHECK: complete --no-files complete_test_alpha2
# CHECK: complete --no-files complete_test_alpha3
# CHECK: complete --force-files t -l fileoption
# CHECK: complete --no-files t -a '(t)'
Add tests for `complete` (no args) output Hopefully this should catch things if the output gets broken again.
2019-09-20 06:01:09 +08:00
# CHECK: complete -p '/complete test/beta1' -s Z -d 'desc, desc'
Support quoted escaping also when ' or \ is present Also, if there are more single quotes than double quotes and dollars, use double quotes for quoting.
2024-04-13 07:00:44 +08:00
# CHECK: complete --require-parameter 'complete test beta2' -d "desc ' desc2 [" -a 'foo bar'
complete: print completions without the implied `-c` switch 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.
2020-10-10 17:54:52 +08:00
# CHECK: complete --exclusive complete_test_beta2 -o test -n false
tests/checks/complete.fish: don't check unsorted lines
2019-09-20 06:44:15 +08:00
# CHECK: complete {{.*}}
# CHECK: complete {{.*}}
# CHECK: complete {{.*}}
# CHECK: complete {{.*}}
Print an error when complete reaches its recursion limit
2019-10-03 13:55:52 +08:00
# Recursive calls to complete (see #3474)
complete -c complete_test_recurse1 -xa '(echo recursing 1>&2; complete -C"complete_test_recurse1 ")'
Consolidate complete cycle detection and always report error on cycle 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.
2020-09-26 20:13:56 +08:00
LANG=C complete -C'complete_test_recurse1 '
Print an error when complete reaches its recursion limit
2019-10-03 13:55:52 +08:00
# CHECKERR: recursing
Raise the recursion limit of complete Users should generally prefer to use complete --wraps but this corrects some unexpected behavior. Fixes #3474
2019-10-03 13:58:04 +08:00
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
# CHECKERR: recursing
Fix error message in tests Switching from the old debug() to flog causes a shift from <E> fish: to error: and in this one place we still test it.
2020-11-08 05:48:13 +08:00
# CHECKERR: error: completion reached maximum recursion depth, possible cycle?
Completion: complete argument to last of a group of short options Consider a group of short options, like -xzPARAM, where x and z are options and z takes an argument. This commit enables completion of the argument to the last option (z), both within the same token (-xzP) or in the next one (-xz P). complete -C'-xz' will complete only parameters to z. complete -C'-xz ' will complete only parameters to z if z requires a parameter otherwise, it will also complete non-option parameters To do so this implements a heuristic to differentiate such strings from single long options. To detect whether our token contains some short options, we only require the first character after the dash (here x) to be an option. Previously, all characters had to be short options. The last option in our example is z. Everything after the last option is assumed to be a parameter to the last option. Assume there is also a single long option -x-foo, then complete -C'-x' will suggest both -x-foo and -xy. However, when the single option x requires an argument, this will not suggest -x-foo. However, I assume this will almost never happen in practise since completions very rarely mix short and single long options. Fixes #332
2019-09-10 20:12:56 +08:00
# short options
complete -c foo -f -a non-option-argument
complete -c foo -f --short-option x
Reindent functions to remove useless quotes This does not include checks/function.fish because that currently includes a "; end" in a message that indent would remove, breaking the test.
2020-03-10 02:36:12 +08:00
complete -c foo -f --short-option y -a ARGY
complete -c foo -f --short-option z -a ARGZ -r
Completion: complete argument to last of a group of short options Consider a group of short options, like -xzPARAM, where x and z are options and z takes an argument. This commit enables completion of the argument to the last option (z), both within the same token (-xzP) or in the next one (-xz P). complete -C'-xz' will complete only parameters to z. complete -C'-xz ' will complete only parameters to z if z requires a parameter otherwise, it will also complete non-option parameters To do so this implements a heuristic to differentiate such strings from single long options. To detect whether our token contains some short options, we only require the first character after the dash (here x) to be an option. Previously, all characters had to be short options. The last option in our example is z. Everything after the last option is assumed to be a parameter to the last option. Assume there is also a single long option -x-foo, then complete -C'-x' will suggest both -x-foo and -xy. However, when the single option x requires an argument, this will not suggest -x-foo. However, I assume this will almost never happen in practise since completions very rarely mix short and single long options. Fixes #332
2019-09-10 20:12:56 +08:00
complete -c foo -f --old-option single-long-ending-in-z
complete -c foo -f --old-option x-single-long
complete -c foo -f --old-option y-single-long
complete -c foo -f --old-option z-single-long
Reindent functions to remove useless quotes This does not include checks/function.fish because that currently includes a "; end" in a message that indent would remove, breaking the test.
2020-03-10 02:36:12 +08:00
complete -c foo -f --long-option x-long -a ARGLONG
Completion: complete argument to last of a group of short options Consider a group of short options, like -xzPARAM, where x and z are options and z takes an argument. This commit enables completion of the argument to the last option (z), both within the same token (-xzP) or in the next one (-xz P). complete -C'-xz' will complete only parameters to z. complete -C'-xz ' will complete only parameters to z if z requires a parameter otherwise, it will also complete non-option parameters To do so this implements a heuristic to differentiate such strings from single long options. To detect whether our token contains some short options, we only require the first character after the dash (here x) to be an option. Previously, all characters had to be short options. The last option in our example is z. Everything after the last option is assumed to be a parameter to the last option. Assume there is also a single long option -x-foo, then complete -C'-x' will suggest both -x-foo and -xy. However, when the single option x requires an argument, this will not suggest -x-foo. However, I assume this will almost never happen in practise since completions very rarely mix short and single long options. Fixes #332
2019-09-10 20:12:56 +08:00
# Make sure that arguments of concatenated short options are expanded (#332)
complete -C'foo -xy'
# CHECK: -xyARGY
# CHECK: -xyz
# A required parameter means we don't want more short options.
complete -C'foo -yz'
# CHECK: -yzARGZ
# Required parameter with space: complete only the parameter (no non-option arguments).
complete -C'foo -xz '
# CHECK: ARGZ
# Optional parameter with space: complete only non-option arguments.
complete -C'foo -xy '
# CHECK: non-option-argument
complete -C'foo -single-long-ending-in-z'
# CHECK: -single-long-ending-in-z
complete -C'foo -single-long-ending-in-z '
# CHECK: non-option-argument
# CHECK: -x-single-long
complete -C'foo -x' | string match -- -x-single-long
# CHECK: -y-single-long
complete -C'foo -y' | string match -- -y-single-long
# This does NOT suggest -z-single-long, but will probably not occur in practise.
# CHECK: -zARGZ
complete -C'foo -z'
Fix completion for builtins (with subcommands) Presently the completion engine ignores builtins that are part of the fish syntax. This can be a problem when completing a string that was based on the output of `commandline -p`. This changes completions to treat these builtins like any other command. This also disables generic (filename) completion inside comments and after strings that do not tokenize. Additionally, comments are stripped off the output of `commandline -p`. Fixes #5415 Fixes #2705
2019-10-29 20:32:26 +08:00
# Builtins (with subcommands; #2705)
completion: adopt commandline -x replacing deprecated -o This gives us more accurate completions because completion scripts get expanded paths
2024-01-22 14:42:45 +08:00
complete -c complete_test_subcommand -n 'test (commandline -xp)[1] = complete_test_subcommand' -xa ok
Fix completion for builtins (with subcommands) Presently the completion engine ignores builtins that are part of the fish syntax. This can be a problem when completing a string that was based on the output of `commandline -p`. This changes completions to treat these builtins like any other command. This also disables generic (filename) completion inside comments and after strings that do not tokenize. Additionally, comments are stripped off the output of `commandline -p`. Fixes #5415 Fixes #2705
2019-10-29 20:32:26 +08:00
complete -C'not complete_test_subcommand '
# CHECK: ok
complete -C'echo; and complete_test_subcommand '
# CHECK: ok
complete -C'or complete_test_subcommand '
# CHECK: ok
complete -C'echo && command complete_test_subcommand '
# CHECK: ok
complete -C'echo || exec complete_test_subcommand '
# CHECK: ok
complete -C'echo | builtin complete_test_subcommand '
# CHECK: ok
complete -C'echo & complete_test_subcommand '
# CHECK: ok
complete -C'if while begin begin complete_test_subcommand '
# CHECK: ok
complete -C'for _ in ' | string collect >&- && echo completed some files
# CHECK: completed some files
# function; #5415
complete -C'function : --arg'
# CHECK: --argument-names {{.*}}
completion: fix file completion of redirection targets This fixes a regression introduced in 6fb7f9b6b - Fix completion for builtins with subcommands
2019-12-16 19:37:41 +08:00
complete -C'echo > /' | string length -q && echo ok
# CHECK: ok
complete: replace confusing comment with test case
2020-01-09 00:53:46 +08:00
function some_function
Run fish_indent on all our fish scripts It's now good enough to do so. We don't allow grid-alignment: ```fish complete -c foo -s b -l barnanana -a '(something)' complete -c foo -s z -a '(something)' ``` becomes ```fish complete -c foo -s b -l barnanana -a '(something)' complete -c foo -s z -a '(something)' ``` It's just more trouble than it is worth. The one part I'd change: We align and/or'd parts of an if-condition with the in-block code: ```fish if true and false dosomething end ``` becomes ```fish if true and false dosomething end ``` but it's not used terribly much and if we ever fix it we can just reindent.
2020-01-14 03:34:22 +08:00
echo line1
echo line2
complete: replace confusing comment with test case
2020-01-09 00:53:46 +08:00
end
complete -c complete_test_function_desc -xa '(complete -Csome_function)'
complete -C'complete_test_function_desc ' | count
# CHECK: 1
Fix completions if previous arg is a variable complete -C'echo $HOM ' would complete $HOM instead of a new token. Fixes another regression introduced in 6fb7f9b6b - Fix completion for builtins with subcommands
2020-01-19 03:20:22 +08:00
complete -c prev-arg-variable -f
complete -C'prev-arg-variable $HOME '
Port "test6" to littlecheck It's related to `complete`, so put it in complete.fish
2020-02-08 17:55:59 +08:00
# Regression test for issue #3129. In previous versions these statements would
# cause an `assert()` to fire thus killing the shell.
complete -c pkill -o ''
#CHECKERR: complete: -o requires a non-empty string
complete -c pkill -l ''
#CHECKERR: complete: -l requires a non-empty string
complete -c pkill -s ''
#CHECKERR: complete: -s requires a non-empty string
# Test that conditions that add or remove completions don't deadlock, etc.
# We actually encountered some case that was effectively like this (Issue 2 in github)
complete --command AAAA -l abcd --condition 'complete -c AAAA -l efgh'
echo "AAAA:"
complete -C'AAAA -' | sort
#CHECK: AAAA:
#CHECK: --abcd
echo "AAAA:"
complete -C'AAAA -' | sort
#CHECK: AAAA:
#CHECK: --abcd
#CHECK: --efgh
complete --command BBBB -l abcd --condition 'complete -e --command BBBB -l abcd'
echo "BBBB:"
complete -C'BBBB -'
#CHECK: BBBB:
#CHECK: --abcd
echo "BBBB:"
complete -C'BBBB -'
#CHECK: BBBB:
Fix complete.fish test It depends on `mktemp -d TAG` returning a relative path, which isn't guaranteed to be the case (and isn't the case when run by our test driver).
2021-03-23 15:12:06 +08:00
#CHECK:
Port "test6" to littlecheck It's related to `complete`, so put it in complete.fish
2020-02-08 17:55:59 +08:00
# Test that erasing completions works correctly
echo
function sort
# GNU sort is really stupid, a non-C locale seems to make it assume --dictionary-order
# If I wanted --dictionary-order, I would have specified --dictionary-order!
env LC_ALL=C sort $argv
end
complete -c CCCC -l bar
complete -c CCCC -l baz
complete -c CCCC -o bar
complete -c CCCC -o foo
complete -c CCCC -s a
complete -c CCCC -s b
echo "CCCC:"
complete -C'CCCC -' | sort
complete -c CCCC -l bar -e
#CHECK: CCCC:
#CHECK: --bar
#CHECK: --baz
#CHECK: -a
#CHECK: -b
#CHECK: -bar
#CHECK: -foo
echo "CCCC:"
complete -C'CCCC -' | sort
complete -c CCCC -o foo -e
#CHECK: CCCC:
#CHECK: --baz
#CHECK: -a
#CHECK: -b
#CHECK: -bar
#CHECK: -foo
echo "CCCC:"
complete -C'CCCC -' | sort
complete -c CCCC -s a -e
#CHECK: CCCC:
#CHECK: --baz
#CHECK: -a
#CHECK: -b
#CHECK: -bar
echo "CCCC:"
complete -C'CCCC -' | sort
complete -c CCCC -e
#CHECK: CCCC:
#CHECK: --baz
#CHECK: -b
#CHECK: -bar
echo "CCCC:"
complete -C'CCCC -' | sort
#CHECK: CCCC:
echo "Test that -- suppresses option completions"
complete -c TestDoubleDash -l TestDoubleDashOption
complete -C'TestDoubleDash -' | sort
#CHECK: Test that -- suppresses option completions
#CHECK: --TestDoubleDashOption
echo "Expect no output:" (complete -C'TestDoubleDash -- -' | sort)
#CHECK: Expect no output:
# fish seems to have always handled "exclusive" options strangely
# It seems to treat them the same as "old-style" (single-dash) long options
echo "Testing exclusive options"
#CHECK: Testing exclusive options
complete -c TestExclusive -x -s Q
complete -c TestExclusive -x -s W
complete -c TestExclusive -s A
echo "Expect -A -Q -W:" (complete -C'TestExclusive -' | sort | string join ' ')
#CHECK: Expect -A -Q -W: -A -Q -W
echo "Expect -AQ -AW:" (complete -C'TestExclusive -A' | sort | string join ' ')
#CHECK: Expect -AQ -AW: -AQ -AW
echo "Expect no output 1:" (complete -C'TestExclusive -Q')
#CHECK: Expect no output 1:
echo "Expect no output 2:" (complete -C'TestExclusive -W')
#CHECK: Expect no output 2:
# Test for optional arguments, like cp's --backup
complete -c TestOptionalArgument -l backup -f -a 'none all simple'
echo "Expect --backup --backup=:" (complete -C'TestOptionalArgument -' | sort | string join ' ')
#CHECK: Expect --backup --backup=: --backup --backup=
echo "Expect --backup=all --backup=none --backup=simple:" (complete -C'TestOptionalArgument --backup=' | sort | string join ' ')
#CHECK: Expect --backup=all --backup=none --backup=simple: --backup=all --backup=none --backup=simple
# Test that directory completions work correctly
Reindent functions to remove useless quotes This does not include checks/function.fish because that currently includes a "; end" in a message that indent would remove, breaking the test.
2020-03-10 02:36:12 +08:00
if begin
rm -rf test6.tmp.dir; and mkdir test6.tmp.dir
end
Port "test6" to littlecheck It's related to `complete`, so put it in complete.fish
2020-02-08 17:55:59 +08:00
pushd test6.tmp.dir
Fix complete.fish test It depends on `mktemp -d TAG` returning a relative path, which isn't guaranteed to be the case (and isn't the case when run by our test driver).
2021-03-23 15:12:06 +08:00
# The "incorrect implicit cd from PATH" fails if mktemp returns an absolute path and
# `realpath --relative-to` is not available on macOS.
# set dir (realpath --relative-to="$PWD" (mktemp -d XXXXXXXX))
set dir (basename (mktemp -d XXXXXXXX))
mkdir -p $dir
fix 'complete' test
2021-11-04 19:18:54 +08:00
if complete -C$dir | string match -r "^$dir/.*dir" >/dev/null
Port "test6" to littlecheck It's related to `complete`, so put it in complete.fish
2020-02-08 17:55:59 +08:00
echo "implicit cd complete works"
else
echo "no implicit cd complete"
end
#CHECK: implicit cd complete works
fix 'complete' test
2021-11-04 19:18:54 +08:00
if complete -C"command $dir" | string match -r "^$dir/.*dir" >/dev/null
Invert test for implicit cd after builtin command Because `command ./somedir/somecommand` is okay. Fixes test failure from aa304cbd3d3. Child directories in $PATH are still not suggested, as was the main intention of the commit that introduced the tests: 8a3cf144f Don't include child directories of $PATH in completions.
2020-03-25 04:55:38 +08:00
echo "implicit cd complete after 'command'"
Port "test6" to littlecheck It's related to `complete`, so put it in complete.fish
2020-02-08 17:55:59 +08:00
else
echo "no implicit cd complete after 'command'"
end
Invert test for implicit cd after builtin command Because `command ./somedir/somecommand` is okay. Fixes test failure from aa304cbd3d3. Child directories in $PATH are still not suggested, as was the main intention of the commit that introduced the tests: 8a3cf144f Don't include child directories of $PATH in completions.
2020-03-25 04:55:38 +08:00
#CHECK: implicit cd complete after 'command'
Port "test6" to littlecheck It's related to `complete`, so put it in complete.fish
2020-02-08 17:55:59 +08:00
popd
if begin
set -l PATH $PWD/test6.tmp.dir $PATH 2>/dev/null
fix 'complete' test
2021-11-04 19:18:54 +08:00
complete -C$dir | string match -r "^$dir/.*dir" >/dev/null
Port "test6" to littlecheck It's related to `complete`, so put it in complete.fish
2020-02-08 17:55:59 +08:00
end
echo "incorrect implicit cd from PATH"
else
echo "PATH does not cause incorrect implicit cd"
end
#CHECK: PATH does not cause incorrect implicit cd
rm -rf test6.tmp.dir
else
echo "error: could not create temp environment" >&2
end
# Test command expansion with parened PATHs (#952)
begin
Reindent functions to remove useless quotes This does not include checks/function.fish because that currently includes a "; end" in a message that indent would remove, breaking the test.
2020-03-10 02:36:12 +08:00
set -l parened_path $PWD/'test6.tmp2.(paren).dir'
set -l parened_subpath $parened_path/subdir
if not begin
rm -rf $parened_path
and mkdir $parened_path
and mkdir $parened_subpath
and ln -s /bin/ls $parened_path/'__test6_(paren)_command'
and ln -s /bin/ls $parened_subpath/'__test6_subdir_(paren)_command'
end
echo "error: could not create command expansion temp environment" >&2
end
# Verify that we can expand commands when PATH has parens
set -l PATH $parened_path $PATH
set -l completed (complete -C__test6_ | cut -f 1 -d \t)
if test "$completed" = '__test6_(paren)_command'
echo "Command completion with parened PATHs test passed"
else
echo "Command completion with parened PATHs test failed. Expected __test6_(paren)_command, got $completed" >&2
end
#CHECK: Command completion with parened PATHs test passed
# Verify that commands with intermediate slashes do NOT expand with respect to PATH
set -l completed (complete -Csubdir/__test6_subdir)
if test -z "$completed"
echo "Command completion with intermediate slashes passed"
else
echo "Command completion with intermediate slashes: should output nothing, instead got $completed" >&2
end
#CHECK: Command completion with intermediate slashes passed
rm -rf $parened_path
Port "test6" to littlecheck It's related to `complete`, so put it in complete.fish
2020-02-08 17:55:59 +08:00
end
Let `complete` show completions for one command if just given `-c` 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`.
2020-09-10 00:03:39 +08:00
# This should only list the completions for `banana`
complete -c banana -a '1 2 3'
complete -c banana
complete: print completions without the implied `-c` switch 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.
2020-10-10 17:54:52 +08:00
#CHECK: complete banana -a '1 2 3'
complete: Make `-c` optional Currently, completions have to be specified like ```fish complete -c foo -l opt ``` while ```fish complete foo -l opt ``` just complains about there being too many arguments. That's kinda useless, so we just assume if there is one left-over argument that it's meant to be the command. Theoretically we could also use *all* the arguments as commands to complete, but that seems unlikely to be what the user wants. (I don't think multi-command completions really happen)
2020-09-10 00:37:46 +08:00
# "-c" is optional
complete banana -a bar
complete banana
complete: print completions without the implied `-c` switch 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.
2020-10-10 17:54:52 +08:00
#CHECK: complete banana -a bar
#CHECK: complete banana -a '1 2 3'
complete: Make `-c` optional Currently, completions have to be specified like ```fish complete -c foo -l opt ``` while ```fish complete foo -l opt ``` just complains about there being too many arguments. That's kinda useless, so we just assume if there is one left-over argument that it's meant to be the command. Theoretically we could also use *all* the arguments as commands to complete, but that seems unlikely to be what the user wants. (I don't think multi-command completions really happen)
2020-09-10 00:37:46 +08:00
# "-a" ain't
complete banana bar
Update tests for changed error output
2021-11-04 13:52:17 +08:00
#CHECKERR: complete: too many arguments
complete: Make `-c` optional Currently, completions have to be specified like ```fish complete -c foo -l opt ``` while ```fish complete foo -l opt ``` just complains about there being too many arguments. That's kinda useless, so we just assume if there is one left-over argument that it's meant to be the command. Theoretically we could also use *all* the arguments as commands to complete, but that seems unlikely to be what the user wants. (I don't think multi-command completions really happen)
2020-09-10 00:37:46 +08:00
#CHECKERR:
#CHECKERR: {{.*}}checks/complete.fish (line {{\d+}}):
#CHECKERR: complete banana bar
#CHECKERR: ^
#CHECKERR:
#CHECKERR: (Type 'help complete' for related documentation)
complete: print completions without the implied `-c` switch 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.
2020-10-10 17:54:52 +08:00
# Multiple commands can be specified, in that case "-c" (or "-p") is mandatory.
complete -c kapstachelbeere -c physalis -a arg
complete -c kapstachelbeere -c physalis
# CHECK: complete kapstachelbeere -a arg
# CHECK: complete physalis -a arg
Honor variable assignments on the commandline when completing files This had already worked before although the implementation used to be rather crude and was cleaned up in https://github.com/fish-shell/fish-shell/commit/e88eb508d060a8749905288b7b68572404870bf3#r42759188
2020-10-10 18:35:20 +08:00
set -l dir (mktemp -d)
echo >$dir/target
complete -C ': $dir/'
# CHECK: $dir/target
rm $dir/target
complete: Obey --force-files without an option Things like ```fish complete command -n '__fish_seen_subcommand_from subcommand' --force-files ``` would not be obeyed because we only checked force-files when there was an option. Fixes #7920.
2021-04-11 03:56:17 +08:00
cd $dir
touch yummyinmytummy
complete -c fudge -f
complete -c fudge -n '__fish_seen_subcommand_from eat' -F
complete -C'fudge eat yummyin'
# CHECK: yummyinmytummy
Stop attempting to complete inside comments Inside a comment we offer plain file completions (or command completions if the comment is in command position). However these completions are broken because they don't consider any of the surrounding characters. For example with a command line echo # comment ^ cursor we suggest file completions and insert them as echo # comsomefile ment Providing completions inside comments does not seem useful and it can be misleading. Let's remove the completions; this should communicate better that we are in a free-form comment that's not subject to fish syntax. Closes #9320
2022-11-13 05:00:36 +08:00
complete -C"echo no commpletion inside comment # "
complete: Obey --force-files without an option Things like ```fish complete command -n '__fish_seen_subcommand_from subcommand' --force-files ``` would not be obeyed because we only checked force-files when there was an option. Fixes #7920.
2021-04-11 03:56:17 +08:00
cd -
rm -r $dir
Resolve relative paths in command names for complete -p Fixes #6001
2021-05-12 05:02:15 +08:00
set -l dir (mktemp -d)
cd $dir
: >command-not-in-path
chmod +x command-not-in-path
complete -p $PWD/command-not-in-path -xa relative-path
complete -C './command-not-in-path '
# CHECK: relative-path
Expand tildes and variables in command for custom completions A «complete -C '~/fish-shell/build/fish '» fails to load custom completions because we do not expand the ~, so complete_param_for_command() thinks that this command is invalid. Expand command tokens before loading custom completions. Fixes #8442
2021-11-27 16:56:35 +08:00
# Expand variables and tildes in command.
complete -C '$PWD/command-not-in-path '
# CHECK: relative-path
HOME=$PWD complete -C '~/command-not-in-path '
# CHECK: relative-path
Resolve relative paths in command names for complete -p Fixes #6001
2021-05-12 05:02:15 +08:00
# Non-canonical command path
mkdir -p subdir
: >subdir/command-in-subdir
chmod +x subdir/command-in-subdir
complete -p "$PWD/subdir/command-in-subdir" -xa custom-completions
complete -C './subdir/../subdir/command-in-subdir '
# CHECK: custom-completions
# Relative $PATH
begin
set -lx PATH subdir $PATH
complete -C 'command-in-subdir '
# CHECK: custom-completions
end
tests/checks/complete: Do $PWD stuff in the tempdir This broke the tests on my machine, and doing ```fish cd $dir cd - ``` seems wrong in any case.
2021-08-30 23:07:11 +08:00
cd -
Resolve relative paths in command names for complete -p Fixes #6001
2021-05-12 05:02:15 +08:00
rm -r $dir
Expand tildes and variables in command for custom completions A «complete -C '~/fish-shell/build/fish '» fails to load custom completions because we do not expand the ~, so complete_param_for_command() thinks that this command is invalid. Expand command tokens before loading custom completions. Fixes #8442
2021-11-27 16:56:35 +08:00
# Expand variables and tildes in command.
complete cat -xa +pet
set -l path_to_cat (command -v cat)
complete -C '$path_to_cat '
# CHECK: +pet
HOME=$path_to_cat/.. complete -C '~/cat '
# CHECK: +pet
# Do not expand command substitutions.
complete -C '(echo cat) ' | string match +pet
# Give up if we expand to multiple arguments (we'd need to handle the arguments).
complete -C '{cat,arg1,arg2} ' | string match +pet
# Don't expand wildcards though we could.
complete -C '$path_to_cat* ' | string match +pet
# Also expand wrap targets.
function crookshanks --wraps '$path_to_cat'
end
complete -C 'crookshanks '
# CHECK: +pet
Fix commandline state for custom completions with variable overrides Today, a command like "var=val status " has custom completions because we skip over the var=val variable override when detecting the command token. However if the custom completions read the commandline state (via "commandline -opc") they do see they variable override, which breaks them, most likely. Try "a=b git ". For completions of wrapped commands, we already set a transient commandline. Do the same for commands with leading variable overrides; then git completions for "a=b git " will think the commandline is "git ".
2022-01-26 22:22:18 +08:00
# Custom completion works with variable overrides.
completion: adopt commandline -x replacing deprecated -o This gives us more accurate completions because completion scripts get expanded paths
2024-01-22 14:42:45 +08:00
complete cmd_with_fancy_completion -xa '(commandline -xpc | count)'
Fix commandline state for custom completions with variable overrides Today, a command like "var=val status " has custom completions because we skip over the var=val variable override when detecting the command token. However if the custom completions read the commandline state (via "commandline -opc") they do see they variable override, which breaks them, most likely. Try "a=b git ". For completions of wrapped commands, we already set a transient commandline. Do the same for commands with leading variable overrides; then git completions for "a=b git " will think the commandline is "git ".
2022-01-26 22:22:18 +08:00
complete -C"a=1 b=2 cmd_with_fancy_completion "
# CHECK: 1
complete -C"a=1 b=2 cmd_with_fancy_completion 1 "
# CHECK: 2
complete: Print better error for -x -F -x is a cheesy shortcut for `-rf`, so it conflicts with `-F`. Fixes #8818.
2022-05-26 20:15:28 +08:00
complete -c thing -x -F
# CHECKERR: complete: invalid option combination, '--exclusive' and '--force-files'
Allow complete to have multiple conditions This makes it so `complete -c foo -n test1 -n test2` registers *both* conditions, and when it comes time to check the candidate, tries both, in that order. If any fails it stops, if all succeed the completion is offered. The reason for this is that it helps with caching - we have a condition cache, but conditions like ```fish test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] length test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] sub ``` defeats it pretty easily, because the cache only looks at the entire script as a string - it can't tell that the first `test` is the same in both. So this means we separate it into ```fish complete -f -c string -n "test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] length" -s V -l visible -d "Use the visible width, excluding escape sequences" +complete -f -c string -n "test (count (commandline -opc)) -ge 2" -n "contains -- (commandline -opc)[2] length" -s V -l visible -d "Use the visible width, excluding escape sequences" ``` which allows the `test` to be cached. In tests, this improves performance for the string completions by 30% by reducing all the redundant `test` calls. The `git` completions can also greatly benefit from this.
2022-05-21 01:02:42 +08:00
# Multiple conditions
complete -f -c shot
completion: adopt commandline -x replacing deprecated -o This gives us more accurate completions because completion scripts get expanded paths
2024-01-22 14:42:45 +08:00
complete -fc shot -n 'test (count (commandline -xpc) -eq 1' -n 'test (commandline -xpc)[-1] = shot' -a 'through'
# CHECKERR: complete: -n 'test (count (commandline -xpc) -eq 1': Unexpected end of string, expecting ')'
# CHECKERR: test (count (commandline -xpc) -eq 1
Allow complete to have multiple conditions This makes it so `complete -c foo -n test1 -n test2` registers *both* conditions, and when it comes time to check the candidate, tries both, in that order. If any fails it stops, if all succeed the completion is offered. The reason for this is that it helps with caching - we have a condition cache, but conditions like ```fish test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] length test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] sub ``` defeats it pretty easily, because the cache only looks at the entire script as a string - it can't tell that the first `test` is the same in both. So this means we separate it into ```fish complete -f -c string -n "test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] length" -s V -l visible -d "Use the visible width, excluding escape sequences" +complete -f -c string -n "test (count (commandline -opc)) -ge 2" -n "contains -- (commandline -opc)[2] length" -s V -l visible -d "Use the visible width, excluding escape sequences" ``` which allows the `test` to be cached. In tests, this improves performance for the string completions by 30% by reducing all the redundant `test` calls. The `git` completions can also greatly benefit from this.
2022-05-21 01:02:42 +08:00
# CHECKERR: ^
completion: adopt commandline -x replacing deprecated -o This gives us more accurate completions because completion scripts get expanded paths
2024-01-22 14:42:45 +08:00
complete -fc shot -n 'test (count (commandline -xpc)) -eq 1' -n 'test (commandline -xpc)[-1] = shot' -a 'through'
complete -fc shot -n 'test (count (commandline -xpc)) -eq 2' -n 'test (commandline -xpc)[-1] = through' -a 'the'
complete -fc shot -n 'test (count (commandline -xpc)) -eq 3' -n 'test (commandline -xpc)[-1] = the' -a 'heart'
complete -fc shot -n 'test (count (commandline -xpc)) -eq 4' -n 'test (commandline -xpc)[-1] = heart' -a 'and'
complete -fc shot -n 'test (count (commandline -xpc)) -eq 5' -n 'test (commandline -xpc)[-1] = and' -a "you\'re"
complete -fc shot -n 'test (count (commandline -xpc)) -eq 6' -n 'test (commandline -xpc)[-1] = "you\'re"' -a 'to'
complete -fc shot -n 'test (count (commandline -xpc)) -eq 7' -n 'test (commandline -xpc)[-1] = to' -a 'blame'
Allow complete to have multiple conditions This makes it so `complete -c foo -n test1 -n test2` registers *both* conditions, and when it comes time to check the candidate, tries both, in that order. If any fails it stops, if all succeed the completion is offered. The reason for this is that it helps with caching - we have a condition cache, but conditions like ```fish test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] length test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] sub ``` defeats it pretty easily, because the cache only looks at the entire script as a string - it can't tell that the first `test` is the same in both. So this means we separate it into ```fish complete -f -c string -n "test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] length" -s V -l visible -d "Use the visible width, excluding escape sequences" +complete -f -c string -n "test (count (commandline -opc)) -ge 2" -n "contains -- (commandline -opc)[2] length" -s V -l visible -d "Use the visible width, excluding escape sequences" ``` which allows the `test` to be cached. In tests, this improves performance for the string completions by 30% by reducing all the redundant `test` calls. The `git` completions can also greatly benefit from this.
2022-05-21 01:02:42 +08:00
complete -C"shot "
# CHECK: through
complete -C"shot through "
# CHECK: the
# See that conditions after a failing one aren't executed.
set -g oops 0
complete -fc oooops
complete -fc oooops -n true -n true -n true -n 'false' -n 'set -g oops 1' -a oops
complete -C'oooops '
echo $oops
# CHECK: 0
complete -fc oooops -n 'true' -n 'set -g oops 1' -a oops
complete -C'oooops '
# CHECK: oops
echo $oops
# CHECK: 1
complete: Don't load completions if command isn't in $PATH This stops us from loading the completions for e.g. `./foo` if there is no `foo` in path. This is because the completion scripts will call an unqualified `foo`, and then error out. This of course means if the script would work because it never calls the command, we still don't load it. Pathed completions via `complete --path` should be unaffected because they aren't autoloaded anyway. Workaround for #3117 Fixes #9133
2022-08-11 23:05:32 +08:00
# See that we load completions only if the command exists in $PATH,
# as a workaround for #3117.
# We need a completion script that runs the command,
# and prints something simple, and isn't already used above.
#
# Currently, tr fits the bill (it does `tr --version` to check for GNUisms)
begin
$fish -c "complete -C'tr -'" | string match -- '-d*'
# CHECK: -d{{\t.*}}
end
set -l tmpdir (mktemp -d)
cd $tmpdir
begin
touch tr
chmod +x tr
set -l PATH
complete -C'./tr -' | string match -- -d
or echo No match for relative
# CHECK: No match for relative
complete -c tr | string length -q
or echo Empty completions
# CHECK: Empty completions
end
Allow custom completions to have leading dots By default, fish does not complete files that have leading dots, unless the wildcard itself has a leading dot. However this also affected completions; for example `git add` would not offer `.gitlab-ci.yml` because it has a leading dot. Relax this for custom completions. Default file expansion still suppresses leading dots, but now custom completions can create leading-dot completions and they will be offered. Fixes #3707.
2022-09-13 06:33:29 +08:00
rm -$f $tmpdir/*
# Leading dots are not completed for default file completion,
# but may be for custom command (e.g. git add).
function dotty
end
function notty
end
complete -c dotty --no-files -a '(echo .a*)'
touch .abc .def
complete -C'notty '
echo "Should be nothing"
# CHECK: Should be nothing
complete -C'dotty '
# CHECK: .abc
complete: Don't load completions if command isn't in $PATH This stops us from loading the completions for e.g. `./foo` if there is no `foo` in path. This is because the completion scripts will call an unqualified `foo`, and then error out. This of course means if the script would work because it never calls the command, we still don't load it. Pathed completions via `complete --path` should be unaffected because they aren't autoloaded anyway. Workaround for #3117 Fixes #9133
2022-08-11 23:05:32 +08:00
rm -r $tmpdir
__fish_complete_command: Fix --foo= logic This was already supposed to handle `--foo=bar<TAB>` cases, except it printed the `--foo=` again, causing fish to take that as part of the token. See #9538 for a similar thing with __fish_complete_directories. Fixes #10011
2023-09-11 00:11:23 +08:00
Test for mktemp completion Turns out fish isn't in $PATH on the CI systems
2023-09-11 22:52:38 +08:00
complete -C'complete --command=mktemp' | string replace -rf '=mktemp\t.*' '=mktemp'
__fish_complete_command: Fix --foo= logic This was already supposed to handle `--foo=bar<TAB>` cases, except it printed the `--foo=` again, causing fish to take that as part of the token. See #9538 for a similar thing with __fish_complete_directories. Fixes #10011
2023-09-11 00:11:23 +08:00
# (one "--command=" is okay, we used to get "--command=--command="
Test for mktemp completion Turns out fish isn't in $PATH on the CI systems
2023-09-11 22:52:38 +08:00
# CHECK: --command=mktemp
builtin commandline: -x for expanded tokens, supplanting -o Issue #10194 reports Cobra completions do set -l args (commandline -opc) eval $args[1] __complete $args[2..] (commandline -ct | string escape) The intent behind "eval" is to expand variables and tildes in "$args". Fair enough. Several of our own completions do the same, see the next commit. The problem with "commandline -o" + "eval" is that the former already removes quotes that are relevant for "eval". This becomes a problem if $args contains quoted () or {}, for example this command will wrongly execute a command substituion: git --work-tree='(launch-missiles)' <TAB> It is possible to escape the string the tokens before running eval, but then there will be no expansion of variables etc. The problem is that "commandline -o" only unescapes tokens so they end up in a weird state somewhere in-between what the user typed and the expanded version. Remove the need for "eval" by introducing "commandline -x" which expands things like variables and braces. This enables custom completion scripts to be aware of shell variables without eval, see the added test for completions to "make -C $var/some/dir ". This means that essentially all third party scripts should migrate from "commandline -o" to "commandline -x". For example set -l tokens if commandline -x >/dev/null 2>&1 set tokens (commandline -xpc) else set tokens (commandline -opc) end Since this is mainly used for completions, the expansion skips command substitutions. They are passed through as-is (instead of cancelling or expanding to nothing) to make custom completion scripts work reasonably well in the common case. Of course there are cases where we would want to expand command substitutions here, so I'm not sure.
2024-01-06 15:45:33 +08:00
## Test token expansion in commandline -x
complete complete_make -f -a '(argparse C/directory= -- (commandline -xpc)[2..];
echo Completing targets in directory $_flag_C)'
var=path/to complete -C'complete_make -C "$var/build-directory" '
# CHECK: Completing targets in directory path/to/build-directory
var1=path complete -C'var2=to complete_make -C "$var1/$var2/other-build-directory" '
# CHECK: Completing targets in directory path/to/other-build-directory
complete complete_existing_argument -f -a '(commandline -xpc)[2..]'
var=a_value complete -C'complete_existing_argument "1 2" $var \'quoted (foo bar)\' unquoted(baz qux) '
# CHECK: 1 2
# CHECK: a_value
# CHECK: quoted (foo bar)
# CHECK: unquoted(baz qux)
complete complete_first_argument_and_count -f -a '(set -l args (commandline -xpc)[2..]
echo (count $args) arguments, first argument is $args[1])'
list=arg(seq 10) begin
complete -C'complete_first_argument_and_count $list$list '
# CHECK: 100 arguments, first argument is arg1arg1
complete -C'complete_first_argument_and_count $list$list$list '
# CHECK: 1 arguments, first argument is $list$list$list
end
## Test commandline --tokens-raw
complete complete_raw_tokens -f -ka '(commandline --tokens-raw)'
complete -C'complete_raw_tokens "foo" bar\\ baz (qux) '
# CHECK: complete_raw_tokens
# CHECK: "foo"
# CHECK: bar\ baz
# CHECK: (qux)
## Test deprecated commandline -o
complete complete_unescaped_tokens -f -ka '(commandline -o)'
complete -C'complete_unescaped_tokens "foo" bar\\ baz (qux) '
# CHECK: complete_unescaped_tokens
# CHECK: foo
# CHECK: bar baz
# CHECK: (qux)
Use fuzzy subsequence completion for options names as well Version 2.1.0 introduced subsequence matching for completions but as the changelog entry mentions, "This feature [...] is not yet implemented for options (like ``--foobar``)". Add it. Seems like a strict improvement, pretty much.
2024-01-28 00:06:10 +08:00
## Fuzzy completion of options
complete complete_long_option -f -l some-long-option
complete -C'complete_long_option --slo'
# CHECK: --some-long-option
complete complete_long_option -f -o an-old-option
complete -C'complete_long_option -ao'
# CHECK: -an-old-option
Only use fuzzy option completion if there is a leading - Commit b768b9d3f (Use fuzzy subsequence completion for options names as well, 2024-01-27) allowed completing "oa" to "--foobar", which is a false positive, especially because it hides other valid completions of non-option arguments. Let's at least require a leading dash again before completing option names.
2024-01-30 14:58:47 +08:00
# But only if the user typed a dash
complete -C'complete_long_option lo'
Reference in New Issue Copy Permalink