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

Suggestion: make g:CommandTMatchWindowReverse default to 1 #187

Closed
lencioni opened this issue Jan 1, 2016 · 7 comments
Closed

Suggestion: make g:CommandTMatchWindowReverse default to 1 #187

lencioni opened this issue Jan 1, 2016 · 7 comments

Comments

@lencioni
Copy link
Contributor

lencioni commented Jan 1, 2016

The reverse option is great because it puts the best suggestion close to where you are typing, and it is in a fixed location. This prevents your eyes from having to bounce around as you use Command-T. In observing people who have set up Command-T, I found that most just use the default order, which unnecessarily slows them down while working. I think that due to its better ergonomics and the low likelihood that people will discover and change the default that this option should be defaulted to 1. What do you think?

@wincent
Copy link
Owner

wincent commented Jan 1, 2016

I agree that this option is an improvement (I've been using it myself ever since it was added, back in April 2011 in commit 3724567 [proof]), and I actually thought about piling together all the potential breaking changes — including toggling this default — in one fell swoop in the 2.0 release. At least some of the Command-T settings in my dotfiles are, by definition, settings that I would consider to be reasonable defaults for most people.

Trouble is, though, the way the Vim plug-in ecosystem works is that most people are tracking the master branch at all times via a plug-in manager, and so the notion of "releases" is becoming less and less meaningful. It means that things like semver and even the very concept of "release notes" become less useful. As a result, I've always been very, very careful about preserving backwards compatibility.

At least for things like renamed or deleted functions I was able to add deprecation warnings in the 2.0 release (see commit afc9442), but I can't really do that for options whose defaults have changed. I may just need to bite the bullet at some point and make the breaking change anyway. For some users it will cause pain, for others, enlightenment, and for others still might just be a UX improvement that goes unnoticed.

@lencioni
Copy link
Contributor Author

lencioni commented Jan 1, 2016

For some users it will cause pain, for others, enlightenment, and for others still might just be a UX improvement that goes unnoticed.

I believe that the number of users that this particular change will cause pain for is relatively low and the solution to the pain is relatively simple. In my mind, the benefit here definitely outweighs the downside, and the earlier you make this change, the more benefit it will have and the less pain it will cause.

wincent added a commit that referenced this issue Jan 1, 2016
@wincent
Copy link
Owner

wincent commented Jan 1, 2016

All right, I pulled the trigger on the next branch.

@wincent wincent closed this as completed Jan 1, 2016
@lencioni
Copy link
Contributor Author

lencioni commented Jan 2, 2016

Awesome! Exciting times we live in.

@sophiebits
Copy link

This surprised me today (hadn't pulled in a while…) but I figured out what changed with a bisect. :)

@lencioni
Copy link
Contributor Author

Sorry about the surprise @spicyj! I'm curious: did you stick with the new default?

@sophiebits
Copy link

I didn't, but I had a fixed height already set. Maybe one day I'll switch.

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

No branches or pull requests

3 participants