Commit graph

14 commits

Author SHA1 Message Date
sudotac
cd82f8cc8e fix(complete): Avoid use of -v in bash completion
Because -v is not supported below bash 5.0.
2024-04-07 23:19:50 +09:00
sudotac
1edffb8576 fix(complete): Prevent filenames splitting
Fix #5313
2024-02-02 23:31:03 +09:00
sudotac
13a79804c9 fix(complete): Suppress a useless space completion 2024-01-20 21:29:51 +09:00
sudotac
e25b1abddf feat(complete): Add DirPath support in bash 2024-01-20 21:29:50 +09:00
sudotac
3a222def22 fix(complete): Fix path completion in bash
Fix #5239
2024-01-20 21:29:06 +09:00
Henry Hsieh
2b48858ba8 fix: Skip nosort option below bash 4.4 2024-01-02 21:14:20 +08:00
Ed Page
35a9d8438e fix(complete): Prefer our own sort order
For testing, I'm seeing different sort orders for local and CI despite
using the same bash version...
2023-07-20 12:14:24 -05:00
clubby789
2f97216156 fix: Respect ValueHint::Other in bash 2023-05-09 20:11:48 +01:00
Fredrik Jansson
3426310d8e fix: Bash test cases 2023-01-23 19:20:09 +01:00
Martin von Zweigbergk
ea264fde16 fix(complete): Fix git diff git <TAB> for Bash
Early in the Bash-completion script, we build up a string that
identifies the command or subcommand. When we see the top-level
command's name (e.g. `git`) we set the command so far to that
value. We do that regardless of where in the argument list it
appears. For example, if the argument list is `git diff git`, we set
the current command to `git` when run into it the second time. We
therefore suggest arguments to the top-level command afterwards, which
is not correct.

This patch fixes that by also considering the string that identifies
the command so far, so we only set the overall command to `git` if the
command so far is the empty string.

This is actually just a step on the way to getting completion to work
for aliases of subcommands.

Closes #4273
2022-09-29 08:40:54 -07:00
Ed Page
02db3043e2 fix(help): Consistently use [] for positionals
In the usaeg we use `[]` but in the arg list we use `<>`.
2022-08-29 15:34:30 -05:00
Ed Page
f70ebe89a7 fix!: Require explicit help/version disabling
Before we introduced actions, it required specific setups to engage with
claps version and help printing.  With actions making that more
explicit, we don't get as much benefit from our multiple, obscure, ways
of users customizing help

Before
- Modify existing help or version with `mut_arg` which would
  automatically be pushed down the command tree like `global(true)`
- Create an new help or version and have it treated as if it was the
  built-in on (I think)
- Use the same flags as built-in and have the built-in flags
  automatically disabled
- Users could explicitly disable the built-in functionality and do what
  they want

Now
- `mut_arg` no longer works as we define help and version flags at the
  end
- If someone defines a flag that overlaps with the built-ins by id,
  long, or short, a debug assert will tell them to explicitly disable
  the built-in
- Any customization has to be done by a user providing their own.  To
  propagate through the command tree, they need to set `global(true)`.

Benefits
- Hopefully, this makes it less confusing on how to override help
  behavior.  Someone creates an arg and we then tell them how to disable
  the built-in
- This greatly simplifies the arg handling by pushing more
  responsibility onto the developer in what are hopefully just corner
  cases
- This removes about 1Kb from .text

Fixes #3405
Fixes #4033
2022-08-10 20:33:21 -05:00
Ed Page
b266e6d35d fix(complete): Complete visible, rather than hidden, values
In a refactor for #3503, one of the checks for `is_hide_set` got flipped
and we are completing hidden `PossibleValue`s rather than visible.

Fixes #3697
2022-05-06 09:14:32 -05:00
Ed Page
55bfacbf43 test(complete): Use official extensions for snapshots 2022-04-22 16:21:10 -05:00
Renamed from clap_complete/tests/snapshots/value_hint.bash.log (Browse further)