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

:V* commands blocking tab complete #178

Closed
Rycieos opened this issue Aug 19, 2016 · 9 comments
Closed

:V* commands blocking tab complete #178

Rycieos opened this issue Aug 19, 2016 · 9 comments

Comments

@Rycieos
Copy link

Rycieos commented Aug 19, 2016

As seen in commit b4f20ff and noted in that commits comments, the commands for V* are still in pathogen, only seeming to exist to explain that they are now in a different plugin. Because these commands are registered, they prevent autocompletion of the same builtin commands.

Ex: type :vsp<TAB>
Expected: vim completes to :vsplit
Actual: vim does not complete and prints two possibilities: Vsplit vsplit

Removing these commands would fix the problem.

@tpope
Copy link
Owner

tpope commented Aug 19, 2016

How are you getting a capitalized command completed from a lowercase input?

@Rycieos
Copy link
Author

Rycieos commented Aug 19, 2016

I assumed that it was a default option, but after a search I discovered that it was the ignorecase option.

It seems weird to me that this applies to commands, but since the smartcase options does not seem to, I will use that instead. This does fix this problem for me, so unless you wanted to remove the warning commands, I will close the issue. Thanks for pointing it out.

@Rycieos Rycieos closed this as completed Aug 19, 2016
@xaizek
Copy link

xaizek commented Aug 19, 2016

@Rycieos, 'smartcase' just modifies behaviour of 'ignorecase' and does nothing if 'ignorecase' isn't set.

@Rycieos
Copy link
Author

Rycieos commented Aug 19, 2016

That would explain why it made the issue go away. I'll reopen this then, since having lazy search is extremely handy. Does anyone know why it is applying to command tab completion instead of just a search?

@Rycieos Rycieos reopened this Aug 19, 2016
@xaizek
Copy link

xaizek commented Aug 19, 2016

I think this code is responsible for the behaviour in question. But I don't understand whether it's planned or accidental, because documentation differs from the code. I personally find the behaviour useful sometimes (e.g. :gc<tab> expands to :Gcommit), but it looks strange and feels like too much for one option (a set-like option that gives more control would be more useful). Maybe this should become an issue in Vim repository?

@Rycieos
Copy link
Author

Rycieos commented Aug 19, 2016

That is a handy feature, I use vim-fugitive as well, and did not know that that was possible with ignorecase. I will leave it on for now, since the benefits outweigh the drawbacks.

I have removed the commands mentioned in this issue from my version of pathogen (Rycieos/vim-pathogen@90220d5e144ceee1b5d83a64703bdd120efe6968), which fixes the problem for me. I will leave it up to @tpope to resolve or close this issue.

As for the setting having weird reaching effects, I agree. I have created vim/vim#991 on this topic.

@mmikeww
Copy link

mmikeww commented Feb 11, 2017

This is so annoying. I really hate tab completing incorrectly

The open PR #138 in 2014 says you are waiting for v3.0 to remove these commands. But then a year later in 2015 in 84a3dd0 the :Vsplit was removed. But then the very next commit Jan 2016 b4f20ff its added back in.

Which also means that the pathogen README is incorrect..

@tpope Are the :Vedit comamnds solely moved to scriptease or not?

@Rycieos
Copy link
Author

Rycieos commented Feb 13, 2017

I agree with @mmikeww, I think that if @tpope took a look at those 2 commits, he would agree with us and revert the revert.

@tpope tpope closed this as completed in 020ab25 Feb 13, 2017
@tpope
Copy link
Owner

tpope commented Feb 13, 2017

I brought them back because I was trying to be diligent about semver and save the removal for 3.0. But it's a dumb user facing feature with a clear migration path so fine, y'all win.

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

No branches or pull requests

4 participants