feat(completions): Override --no-files for path-like inputs#12015
feat(completions): Override --no-files for path-like inputs#12015abelcha wants to merge 2 commits intofish-shell:masterfrom
Conversation
Many command-line tools have completions that list available subcommands and intentionally disable file completions with --no-files to avoid cluttering the suggestions. However, this becomes problematic when a user genuinely needs to provide a file path to the command. A great example is a command like `cursor`, which might have the following subcommands: ``` > cursor <TAB> tunnel (Make the current machine accessible from vscode.dev) serve-web (Run a server that displays the editor UI in browsers) agent (Start the Cursor agent in your terminal) ``` The completions for `cursor` would be defined with --no-files to only show this list of subcommands. The issue is that if the user wants to operate on a file in the current directory, they get no help: ``` > cursor ./<TAB> # (no completions appear) ``` This change improves the user experience by introducing an intuitive override. If the token being completed starts with a `.` or `/`, we now assume the user is providing a path and force file and directory completions to appear, even if --no-files was specified for the command. With this change, the behavior becomes: ``` > cursor ./<TAB> ./file.txt ./src/ ./README.md ``` This provides helpful, contextually-aware completions exactly when the user needs them, without requiring any changes to existing completion scripts.
|
This would break cases like Instead, use --force-files in your completion script. |
Thats a case i had in mind, for example if i want to force add a .gitignored file, it wont complete |
|
Thats a case i had in mind, for example if i want to force add a .gitignored file, it wont complete
there are always cases where you want to complete any file
Right, the false negatives with Git are annoying.
I'd frequently need to add "--" to commands like "git checkout" to get working file completions.
Also, file completions work also on tokens with special characters like $ {} ~.
Let's try to fix the completion scripts. Not sure where's the cursor one.
For "git add", maybe a start is to enable file completion if the "-f" flag is given.
I wonder if we should fall back to file completions when there is no result I think there was a discussion about this somewhere.
|
There wasn't just a discussion about it, that was what fish originally did and we fixed it because it wasn't a good idea. |
i agree and it should be the behavior by default, |
|
reopening to fix at least
Only falling back to file completions if there are no user-defined ones AND the prefix is either |
Many command-line tools have completions that list available subcommands and intentionally disable file completions with --no-files to avoid cluttering the suggestions. However, this becomes problematic when a user genuinely needs to provide a file path to the command.
A great example is a command like
cursor, which might have the following subcommands:The completions for
cursorwould be defined with --no-files to only show this list of subcommands. The issue is that if the user wants to operate on a file in the current directory, they get no help:This change improves the user experience by introducing an intuitive override. If the token being completed starts with a
.or/, we now assume the user is providing a path and force file and directory completions to appear, even if --no-files was specified for the command.With this change, the behavior becomes:
This provides helpful, contextually-aware completions exactly when the user needs them, without requiring any changes to existing completion scripts.