Case-insensitive tab completion

[benmullins]

I'd like to suggest an option to make tab completion fully case-insensitive. What I mean, for example, is the following situation: I have in my home directory two subdirectories, one starting with uppercase P and the other with lowercase p. For the last year or so I've been using zsh with oh-my-zsh, and I've grown accustomed to getting into the directory starting with uppercase P by typing cd p, hitting tab twice, and choosing the correct directory of the two.

Besides that inconvenience, the current behavior feels somewhat inconsistent to me. If I type, for example, cd N, it matches directories starting with lowercase n, and cd v matches directories starting with uppercase V --- because I don't have directories starting with that letter in the other case. So essentially it matches case-insensitively sometimes but not always; specifically iff there are no case-sensitive matches. This confused me a fair bit when I first discovered the behavior, since I was using fish for a little while before I ran into the cd p issue I described, and it took me a while to realize why it was immediately auto-completing to the lowercase p directory without giving me a choice.

I understand why this behavior might be undesirable to some people since Unix filesystems are generally case-sensitive, and I know that configurability is the root of all evil and all, but I found this to be something of a pain point while trying fish.

fish version: 2.5.0, stock standard from Homebrew
OS: macOS 10.12.4
Terminal: Terminal.app

[faho]

First some facts and definitions:

I'd call what we currently have "case-correcting". I.e. when what you entered can't match a completion, fish tries matches that only differ by case.

An obvious variation on this theme (inspired by vim's "smartcase" search option) is to do case-insensitive matching if the input is all lower-case, and case-sensitive otherwise. Let's call this "smartcase".

Compare #1196, which asks for case-insensitivity specifically for the "fuzzy" completions.

---

The advantage of case-sensitive searching (CSS) is that you can get down to fewer options faster iff you know what case what you are looking for is.

The advantage of case-insensitive searching (CIS) is that you get more options if you don't know (or remember) the case.

The failure mode of CSS (i.e. you enter something in the wrong case) is that you either get the wrong or no option - case-correction removes that "no" options case. When this happens, you need to remove the already picked option (if any) and then change the case of the offending character. But to do that, you need to know which character is wrong.

The failure mode of CIS is that you get more options and need to pick from them. Which is something that you already need to be prepared to do, and which can be made easier with e.g. a nice searchable pager (:wink:).

So I'd argue for case-insensitivity here, possibly with "smartcase" (which is essentially an optimization for when you remember the case, with the caveat that you can only use it if something is uppercase), though that doesn't seem too useful specifically for completions.

One possible issue here is that case-insensitivity is locale-dependent. Consider the humble "i". If you're turkish, that's the lower-case version of "İ". See https://en.wikipedia.org/wiki/Dotted_and_dotless_I and #2241. Or "ß", which upcases to "SS" in Germany.

But for completions, it seems that this isn't much of a problem, since people don't regularly change their locale and would just get used to how it behaves on their system. It also seems unlikely they'd enter foreign characters (I don't think turkish keyboards even have a "ß").

I have in my home directory two subdirectories, one starting with uppercase P and the other with lowercase p.

Note that the obvious workaround is renaming one of the directories.

[olets]

Note that the obvious workaround is renaming one of the directories.

There are many scenarios where renaming won't be a good option or even an option at all, and ideally fish's ergonomics wouldn't be limited by files'/directories'/commands' cases.

I have the same expectation as the OP: that for

$ ls .
mydir1
Mydir2

fish would consider Mydir2 a possible match for $ m<TAB>. The behavior would be the fish standard: first tab would complete with the top ranked suggestion, second tab would open a completion menu. Currently mydir1 is considered the perfect match, and a second tab drills into mydir1.

Per #5193 adding smart case completion would address this, as m… and M… would both be matches for m.

[mnemnion]

This behavior is bad enough that I consider it a bug.

I will type git branch -d and fish will 'helpfully' autocorrect it to -D, which is dangerous (it seems to do it when I've recently used the -D flag). I've considered abandoning fish shell because of this specific behavior.

[ridiculousfish]

@mnemnion note the d->D is a suggestion only; it doesn't actually change what you typed, or what is executed if you press enter (unless you accept the suggestion). If you continue typing what you had in mind, the case will revert to what you typed.

The reason is that mixed-case autosuggestions end up looking quite weird. I agree it's not ideal and am open to suggestions for improvements.

[mnemnion]

That's good to know, I always stop cold and go back to delete it. I like fish a lot for the suggestions and autocomplete, but changing the case of a flag I've already typed is alarming.

My suggestion would be that in the case of flags, this shouldn't happen. A capitalized flag is going to be different from a lowercase flag in all cases I can think of.

[krobelus]

I guess history and flag autosuggestions should be case-sensitive, but file autosuggestion probably not.