Vim: Option to disable text object plugins

[DanielFabian]

Describe the bug
When I am in normal mode, and I type cie (usually a typo, trying to type ciw), it deletes the whole document and puts into insert mode. Is that inteded? Vim itself acts like ciw.

To Reproduce
Steps to reproduce the behavior:

Open a document with some text. From normal mode cie.

Expected behavior
I haven't found what the intended behaviour is on any vim docu, but vim seems to act like ciw.

Environment (please complete the following information):

• Extension (VsCodeVim) version: 1.14.5
• VSCode version: 1.46.1
• OS: Window_NT x64 10.0.19041

Additional context
none.

[J-Fields]

Is that intended?

Yeah, we emulate https://github.com/kana/vim-textobj-entire

but vim seems to act like ciw

Are you sure you don't have a mapping to make it behave this way? I can't reproduce

[DanielFabian]

Ah, that makes sense. I don't have the plugin in vim. So vim presumably parses it as change inner end of word.

Is there a way in vscodevim to disable it then? I'm perfectly happy ggcG, but cie is so close to ciw that I mistype it frequently. And the plugin's undo is very sluggish taking often seconds on a whole document.

[J-Fields]

Currently, I don't think so. You should be able to map e to w in operator-pending mode once #4735 is merged

[berknam]

Currently, I don't think so. You should be able to map e to w in operator-pending mode once #4735 is merged

Actually you will have to map ie to iw in operator-pending mode. And that is probably the way you are currently getting Vim to do a 'change inner word' when pressing cie. Either you have a line like this omap ie iw on your .vimrc or you have a Plugin doing that map. Try to run :omap ie on your Vim and see if it has something (or :map cie).

[DanielFabian]

both of them say "no mapping found".

[DanielFabian]

I'm a bit confused actually. (Also empty .vimrc, it has some default global vim settings as per Ubuntu in WSL2, but not much).

[berknam]

That's strange. AFAIK Vim by default doesn't have any motion of ie. Does it work as well in visual mode? If you do ie in visual mode does it select inner word?

[DanielFabian]

Sorry, I just double-checked cie really does nothing. Whereas in vscode, the ie is recognized and deletes the whole document.

That wouldn't be that bad by itself u is pretty close after all. Unfortunately after working for a while, (especially when the file was reformatted), the u can take multiple seconds and it hangs the vscodevim extension. For me, having an option to disable this behaviour much like we have for easymotion, say, would fix the problem nicely.

[DanielFabian]

Should I close this and make a feature request instead for adding the option to disable this particular binding? Or will that refactoring that's pending already add some options to changing the binding?

[berknam]

As @J-Fields said, after #4735 gets merged you'll be able to remap the operator-pending mode ie to iw. But having an enable/disable option for that plugin could also be a good feature, specially when the #4653 gets merged. In that case I don't know if we should have an option to disable all text-object plugins (i.e. the text-object-entire and the text-object-arguments) or if there should be an option for each one?

[DanielFabian]

My first guess would be that given the non-trivial amount of options we already have and given that all the other "plugin-like" features are toggles, I'd personally vote for a global option. And leave individual options to manual rebinding.

[ronakg]

+1 to this. I think there should be an option to disable all built-in plugins or any non-native vim functinoality should be opt-in.

[J-Fields]

@ronakg Out of curiosity, why do you mind a purely additive plugin being enabled by default?

[ronakg]

It's more to do with how a piece of software should ship out of the box. This is a vim emulator for VSCode, so out of the box, it should behave like how vim behaves out of the box as much as possible.

Every plugin enabled by default adds some non-zero additional processing during insert/normal mode depending on the plugin, which should be up to the user to decide IMO.

[J-Fields]

Every plugin enabled by default adds some non-zero additional processing during insert/normal mode depending on the plugin, which should be up to the user to decide IMO.

This really isn't true in VSCodeVim's case, there's no performance impact of having a plugin enabled unless you actually use it