wincent / command-t

⌨️ Fast file navigation for Neovim and Vim
BSD 2-Clause "Simplified" License
2.74k stars 317 forks source link

Messing with users vim settings (switchbuf) #309

Closed leigh-ols closed 6 years ago

leigh-ols commented 6 years ago

See 237 and 246

I believe it is incorrect to have made this the default behavior, at least in the manner it has been implemented.

The current implementation is changing a users vim settings in a way that cannot be prevented in vimrc, only overridden after the fact.

If a user wants switchbuf='' then at present command-t changes this to switchbuf=usetab. The only way to override this behavior is to then change it back again after command-t has loaded.

The argument can also be made that it isn't a plugins job to change a users vim settings to what it thinks are the best defaults, at least not unless those vim settings are absolutely required for the correct functioning of the plugin, which doesn't apply in this case.

If usetab is to remain as default for command-t (which personally I don't think it should, after all it isn't the vim default for a reason) then it should be implemented in a way which doesn't alter users existing built in vim settings. Or at the very least in a way that allows the user to prevent this behavior in their standard vimrc without resorting to auto-commands that must be run after command-t has loaded.

--- edit---

On a side note, has something changed that prevents Command-T from opening in the current window?

Mine seems to have started opening in a split, I wonder if it's a change to the code or to my vimrc..?

wincent commented 6 years ago

You should be able to override the setting by configuring it in the "after" directory (see :h after-directory). (And I should probably note this in the docs.)

Like many things in software design, what you are observing here is a trade-off. Ideally, plug-ins wouldn't override user settings. In this case, it does in order to deliver a better user experience for most of the users (who would otherwise complain about stuff opening in new splits etc), and only because there is the "escape hatch" of the "after" directory that exists for users who disagree.

Nothing has changed that would make Command-T open in a split; it's probably some interaction with settings in your vimrc or other plug-ins. The most critical part of the logic for opening is here:

https://github.com/wincent/command-t/blob/c5882de56f0ca3ce8e891c434f192519aca5c7bb/autoload/commandt.vim#L159-L173

If you find that it doesn't work properly with your set-up and there is some reason why you can't change your set-up you can override the settings listed under :CommandTOpen to use different commands:

https://github.com/wincent/command-t/blob/c5882de56f0ca3ce8e891c434f192519aca5c7bb/doc/command-t.txt#L616-L626

leigh-ols commented 6 years ago

Thanks for your concise and timely response!

I understand it can be overridden in the after directory, however this is forcing people to create a new directory + file and split the location of their vim settings logic, just to hold a single command to restore what is the default vim behavior.

Personally I disagree with the decision, I'm likely biased because this isn't my use case, but I think the fact that this isn't default vim behavior is a strong argument against the decision, or at very least the implementation.

I understand you are attempting to make life easier for the majority, but under the current implementation it's at the expense of making life much more difficult (and confusing) for everyone else.

I can see i'm not going to be able to convince you that those that want this behavior should just set switchbuf=usetab manually so what if we changed the implementation?

Have a var g:CommandTSwitchTabs=1, CommandT can then check if this variable exists, if it doesn't create it and set switchbuf=usetab. That way it remains default and then users that don't want this behavior can just let g:CommandTSwitchTabs=0in their standard vimrc, disabling CommandT's slightly obtrusive behavior.

The present solution has other flaws, such as if switchbuf is set to anything else (useopen, split, vsplit, newtab) then usetab doesn't get set. So if a user has customized their setting they don't get your default behavior, yet if they want the default vim behavior they have to jump through hoops to get it, this lacks consistency.

What do you think?

leigh-ols commented 6 years ago

In the mean time for those who don't want to use a file in the after dir, you can put this in your vimrc:

au VimEnter * set switchbuf=

This will wait until after CommandT has loaded and then run set switchbuf=

nlsun commented 6 years ago

Alternatively, you can set switchbuf explicitly to the default behavior:

set switchbuf=useopen

This will behave the same as switchbuf='', and additionally it will prevent command-t from overriding it.

Also, for anyone using Ack.vim or any plugin that uses the quickfix window, this will impact their buffer opening behavior.

leigh-ols commented 6 years ago

Whoops,.. well now I feel dumb! I could have swore I tried that directly in vim and got these results:

set switchbuf=useopen
set switchbuf
----------------
   switchbuf=
----------------

I must have typo'd useopen without realizing it!

Closing as this stupidly simple solution solves the main issue.