Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support smart case when completing common prefix in edit:completion:smart-start #893

Open
hanche opened this issue Jan 2, 2020 · 4 comments
Open

Comments

@hanche
Copy link

@hanche hanche commented Jan 2, 2020

Given this setup:

edit:completion:matcher[argument] = [seed]{ edit:match-prefix $seed &ignore-case=$true }

If I try to complete a filename and there is only one match, but the case of what I typed does not match the filename, I get a completion list containing just one element. For example, after typing ls doc (all lower case) and hitting TAB, I get this ( is my prompt. I removed the right prompt)

⬥ ls Documents/
 COMPLETING argument
Documents

What I expected is what is seen on the command line above, without the two extra lines and no need to hit RETURN to continue. That is what happens if I type ls Doc and hit TAB.

@xiaq xiaq changed the title Case insensitive completion Case insensitive completion does not auto-accept Jan 2, 2020
@xiaq xiaq changed the title Case insensitive completion does not auto-accept Case insensitive completion does not auto-accept lone candidate Jan 2, 2020
@xiaq xiaq changed the title Case insensitive completion does not auto-accept lone candidate Case insensitive completion does not auto-accept lone candidate with different case Jan 2, 2020
@xiaq xiaq removed the t:bug label Jan 2, 2020
@xiaq

This comment has been minimized.

Copy link
Member

@xiaq xiaq commented Jan 2, 2020

OK, this actually is a feature. Citing https://elv.sh/ref/edit.html#editcompletionsmart-start:

Starts the completion mode. However, if all the candidates share a non-empty prefix and that prefix starts with the seed, inserts the prefix instead.

There is no special handling for automatically accepting a single candidate; it falls in the general case; when there is only a single candidate, the non-empty prefix is that candidate itself.

However, edit:completion:smart-start only inserts the prefix if it also starts with the seed. In this case, the seed is de (lower case), while the prefix is Desktop (with an upper-case D). So the prefix insertion path is not triggered.


Consider this case: you have a substring matcher, and you have foo and bar in a directory. Typing vim o<Tab> completes to a single candidate foo. Since foo does not start with the seed o, Elvish opens up the completion menu. This is because there is a non-zero chance that you have mistyped and did not mean to complete foo. So this is Elvish asking you "are you sure you want to complete foo"?

The same can be said for this issue, but the point is a bit weaker. Often we know that Desktop starts with a capital D, but we are just too lazy to press that Shift key. So when I type vim de<Tab>, there is actually a very high chance that I do mean to complete Desktop.

I think there is a case for edit:completion:smart-start to ignore the case or apply smart-case when determining whether prefix completion should be done. It can accept &smart-case or &ignore-case like the matchers do, and we can default to &smart-case.

@xiaq xiaq changed the title Case insensitive completion does not auto-accept lone candidate with different case Support smart case when completing common prefix in edit:completion:smart-start Jan 3, 2020
@hanche

This comment has been minimized.

Copy link
Author

@hanche hanche commented Jan 3, 2020

Thanks for the explanation. I don't suppose it would be possible to write elvish code to override the behaviour of edit:completion:smart-start? The documentation seems a bit sparse on that point.

@xiaq

This comment has been minimized.

Copy link
Member

@xiaq xiaq commented Jan 3, 2020

No, you can't do that in Elvish code. The Go code needs to be changed.

@hanche

This comment has been minimized.

Copy link
Author

@hanche hanche commented Jan 3, 2020

Okay, good to know. I'll be happy to see a fix, but it's not a high priority to me. It's merely a minor irritant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.