Messing with users vim settings (switchbuf)

[leigh-ols]

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]

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:

command-t/autoload/commandt.vim

Lines 159 to 173 in c5882de

	function! commandt#GotoOrOpen(command_and_args) abort
	let l:command_and_args = split(a:command_and_args, '\v^\w+ \zs')
	let l:command = l:command_and_args[0]
	let l:file = l:command_and_args[1]
	" `bufwinnr()` doesn't see windows in other tabs, meaning we open them again
	" instead of switching to the other tab; but `bufname()` sees hidden
	" buffers, and if we try to open one of those, we get an unwanted split.
	if bufwinnr('^' . l:file . '$') != -1 ||
	\ (bufname('^' . l:file . '$') !=# '' && !s:BufHidden(l:file))
	execute 'sbuffer ' . l:file
	else
	execute l:command . l:file
	endif
	endfunction

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:

command-t/doc/command-t.txt

Lines 616 to 626 in c5882de

	*:CommandTOpen*
	|:CommandTOpen| The default command used by the various "AcceptSelection"
	settings (|g:CommandTAcceptSelectionCommand|,
	|g:CommandTAcceptSelectionTabCommand|,
	|g:CommandTAcceptSelectionSplitCommand|, and
	|g:CommandTAcceptSelectionVSplitCommand|) to open the
	selected item. Implements smart "goto or open" logic that
	will try to focus an existing, previously opened instance of
	the selected item if possible, and only open a new tab or
	split as a last resort. To work most usefully, should be
	used with Vim's |'switchbuf'| setting set to "usetab".

[leigh-ols]

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=0 in 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]

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]

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]

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.