Open lzybkr opened 11 months ago
A couple more issues I've observed:
\
on Windows unexpectedly results in no matchesExamples:
nvim C:\Windows\wTab
nvim C:/Windows/*wTab
Backslash filepaths are indeed not supported in carapace. Other shells use forward slash and Powershell can do so as well. Maybe in the future, but for now there is no plan to add it.
Wildcard expansion is also not supported.
There are some options for globbing.
But often there is not differentiation possible between quoted/escaped globs and those that aren't.
There is a similar issue with ~
wich is simply assumed unquoted when it prefixes a path.
Carapace intentionally has no file completion fallback. This only seems helpful because shell completions so far were often incomplete. Most of the time it is simply wrong.
Carapace does its own file completion as:
LS_COLORS
git -C ../other-dir add <file in other-dir>
)file://<path>
and key=<path>
In general, if the completion is expecting a filename but the only valid matches are directories, carapace should complete directories.
This should actually be already the case (see ActionFiles and ActionDirectories)
On Windows, filenames are case insensitive so carapce should ignore case.
Generic case-insensitive matching can be enabled: https://github.com/rsteube/carapace-bin/discussions/1791
Request
I'm using carapace on Windows with PowerShell, not sure if the issues I'm seeing are relevant elsewhere.
Filename completion works inconsistently when using carapace versus not.
Example:
notepad c:\winTab
Versus:
nvim c:\winTab
The former will complete to
C:\Windows
whereas the later doesn't complete anything.Proposed solution
carapace should try to match the shell's native completion matching.
In general, if the completion is expecting a filename but the only valid matches are directories, carapace should complete directories. On Windows, filenames are case insensitive so carapce should ignore case.
Maybe not the best option but for many commands like
nvim
where carapace may get in the way of returning useful results, just return nothing and let the default PowerShell completion fallback take over.For other commands like
git
, this might not be a great option and result in an inconsistent experience, so I would at least consider trying to match the shell's behavior somewhat.Anything else?
No response