You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering if there is a way for carapace to enable completion case-insensitive matching, which is especially useful for file completion. I quickly checked that this not working was not due to system shell settings; it's not (if you have a Downloads dir in your $HOME, try some file completion with -f D, and it won't propose it.
Maybe the context/reason for which I'm requesting will help (at least help deciphering the proposed solution section):
I have a readline library, which strives to be compatible with the original readline bash library (which itself has an insensitive matching option).
Using carapace along with this library is great and easy: as you know, consumers of carapace don't really need to bother with (prefix) matching logic. But the downside is precisely that case-insensitive matching cannot "be forced".
Proposed solution
I don't really have an idea right now, as I've not really thought about it. However:
The first way would be to add a setting to the carapace configuration, however I'm not really sure this is great.
Or, simply replace the various strings.HasPrefix() calls with something that is case insensitive by default, and let the system shells handle their filtering. It seems to me that this would be better, as shells like bash/zsh have native options for this, and it works well out of the box.
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Yeah case insensitive is a bit of an issue. Had some thoughts on it before but so far case sensitive is pretty much what works.
The shell can handle filtering the results insensitive during menu completion (e.g. filtering in elvish), but for generating them carapace might pass the args to other services/commands where the case matters.
There's limited possibility to filter the results insensitive in carapace, but at the moment i expect it to cause more issues than benefit.
There are good reasons for it though like the kill signals which i chose to complete in uppercase, but can be lowercase as well.
I have my eyes on it but so far couldn't think of a solution i am happy with.
Yes the problems would seem not so much to appear in things like command/filename completion stuff, but in the myriad other completers that are part of carapace (carapace-bin I guess, for most of them).
Thanks, looking forward to a solution to that, but yes please keep your fantastic library working !
Request
Hello Rob,
I was wondering if there is a way for carapace to enable completion case-insensitive matching, which is especially useful for file completion. I quickly checked that this not working was not due to system shell settings; it's not (if you have a
Downloads
dir in your$HOME
, try some file completion with-f D
, and it won't propose it.Maybe the context/reason for which I'm requesting will help (at least help deciphering the proposed solution section):
I have a readline library, which strives to be compatible with the original
readline
bash library (which itself has an insensitive matching option).Using carapace along with this library is great and easy: as you know, consumers of carapace don't really need to bother with (prefix) matching logic. But the downside is precisely that case-insensitive matching cannot "be forced".
Proposed solution
I don't really have an idea right now, as I've not really thought about it. However:
strings.HasPrefix()
calls with something that is case insensitive by default, and let the system shells handle their filtering. It seems to me that this would be better, as shells likebash
/zsh
have native options for this, and it works well out of the box.Anything else?
No response
The text was updated successfully, but these errors were encountered: