Cmd+D loses multiple selections

[timkendrick]

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

What happened: After a recent VSCodeVim update (since v0.10.12?), pressing Cmd+D sometimes loses multiple selections

What did you expect to happen: Selections should be maintained when using Cmd+D to select multiple occurrences

How to reproduce it (as minimally and precisely as possible):

• In normal mode, position the cursor within a word that is repeated within the current buffer
• Press viw to select the current word in visual mode
• Press Cmd+D; another cursor is created at the next occurrence, and the status bar indicates that the editor is still in visual mode, however the selection is lost and the cursors are moved to one character after the ends of the words (preventing the ability to use c to replace both selected occurrences).

Environment: macOS

• Extension (VsCodeVim) version: 0.10.3
• VSCode version: 1.19.2
• OS version: 10.12.6

[timkendrick]

UPDATE: It looks like I was mistaken about this being related to Ctrl-D, as Cmd+D seems to work intermittently (I can't figure out what triggers the bug). I've updated the issue title/description to reflect this.

[rhys-vdw]

I am experiencing this problem today as well - but not intermittently, it happens every time the second selection is made.

me pressing cmd+d repeatedly on @extend☝️

[jpoon]

We changed the default behaviour of <C-d> with #2269.

handleKeys	behaviour
true	VSCodeVim move page half down
false	remap to <D-d>
undefined	VS Code default behavior

Try setting the handleKeys setting to the appropriate configuration you want.

[timkendrick]

@jpoon as mentioned in my comment above, that doesn’t seem to fix the problem unfortunately - also it seems weird that the setting for Ctrl-D should have an effect on the Cmd-D behavior?

[redhat008]

me too. change the handleKeys setting not working.

[Chillee]

@rhys-vdw What are your config settings? Also, can you send me that file? I couldn't replicate on some basic tests.

[chatziko]

Not sure if this is related to this issue, but I think it's worth mentioning it:

#2314 made vim.handleKeys default to { "<C-d>": true }. So, in combination with #2269, if one only has:

"vim.useCtrlKeys": false,

then <C-d> is mapped to move page half down, which is not what I'd expect.

Even worse, the following config:

"vim.useCtrlKeys": false,
"vim.handleKeys": {}

still causes <C-d> to move page half down. Maybe vscode uses default values for each sub-key independently? (not sure). So it seems that handleKeys."<C-d>" can never be undefined! (the third option of the table is impossible)

Luckily in linux I don't think there's a difference between "remap to " and "VS Code default behavior" so the following:

"vim.useCtrlKeys": false,
"vim.handleKeys": { "<C-d>": false }

does restore the default behaviour (add selection to next find match) for me. Still I find it very weird that I need to configure it like that (and even more weird that my previous simple config useCtrlKeys: false suddenly stopped working).

[jpoon]

Yes, when we were discussing that PR, we fucked up and chose the wrong default. However, at this point, we're stuck with it unless we want to break all the other people that have made their changes to their configs.

For the <C-d>, useCtrlKeys is pretty much ignored. The only setting that is taken into consideration is handleKeys.

handleKeys	behaviour
true	VSCodeVim move page half down
false	remap to <D-d>
undefined	VS Code default behavior (add selection to next find match)

where undefined means, there's no setting for <C-d> in handleKeys. It's funny you aren't seeing a behaviour change, we do hot-reloading of the configs, but just in case, can you restart Code following your config updates?

[chatziko]

I just tested it on a clean installation, with only the vim extension installed, and reload between tries.

All the following configurations:

1. empty config
2. "vim.handleKeys": { }
3. "vim.handleKeys": { ..anything here other than <C-d>.. }
4. "vim.handleKeys": { "<C-d>": true }

map C-d to "move page half down". It's as if vscode sets an entry "<C-d>": true if there's no C-d in handleKeys. I wonder whether this:

Vim/package.json

Lines 515 to 521 in 68e793f

	"vim.handleKeys": {
	"type": "object",
	"description": "Option to delegate certain key combinations back to VSCode to be handled natively",
	"default": {
	"<C-d>": true
	}
	},

means:

• set "vim.handleKeys", if missing, to { "<C-d>": true }, OR
• set "vim.handleKeys.<C-d>", if missing, to true ?

Only:

5. "vim.handleKeys": { "<C-d>": false }

causes C-d to do "add selection to next find match".

[jpoon]

1. and 2. are equivalent
2. should be vim.handleKeys": { "<C-d>": false }

handleKeys	behaviour
vim.handleKeys":{"<C-d>": true}	VSCodeVim move page half down
vim.handleKeys":{"<C-d>": false}	remap to <D-d>
vim.handleKeys":{ } OR no value for <C-d>	VS Code default behavior (add selection to next find match)

causes C-d to do "add selection to next find match".

What you are seeing is VSCodeVim handling that.

[timkendrick]

I think the conversation's getting a little sidetracked: the handleKeys PR is at #2269, whereas this is a separate issue about losing multiple selections.

As far as I can tell, the two issues are totally unrelated, especially seeing as this occurs when running the Selection > Select Previous Occurrence menu item which is nothing to do with the <C-d> shortcut.

[Chillee]

@timkendrick I'm not convinced they're entirely unrelated. We had to add special handling for ctrl+d, so if they're not bound properly, that's probably the issue you're seeing.

[timkendrick]

Ah ok, sorry – I was assuming that they were unrelated seeing as this bug also occurs when using the Selection > Add Previous Occurence menu command, which doesn't even have a keyboard shortcut bound to it. Maybe there's something internal that links the two though.

[ysjn]

Hi. I've run into the same problem.
But it seems opening a new file fixes this issue as woowoole mentioned in #2331.

[rgehan]

My environment:

• Extension (VsCodeVim) version: 0.11.0
• VSCode version: 1.20.1
• OS version: Mac OS Sierra 10.12.6

I've created the issue referenced above.

---

1. ⚠️ { 'vim.useCtrlKeys': false, 'vim.handleKeys': { '<C-d>': false } }

• Pressing Ctrl+D (normal/insert mode) does incrementally select instances of the first selection; but it scrolls back to the first selection instead of focusing the last selection
• Pressing Cmd+D (normal/insert mode) only select the second instance, then moves to the end of the two selections, preventing the user to press c to edit the two selections (as @rhys-vdw showed)

Adding '<D-d>': true|false doesn't change a thing.

2. ⚠️ { 'vim.useCtrlKeys': true, 'vim.handleKeys': { '<C-d>': true } }

• Pressing Ctrl+D / Ctrl+U (normal/insert mode) now scrolls half a page up or down (which is a cool feature)
• Pressing Cmd+D (normal/insert mode) still select two instances of the initial selection, then moves to the end of the selections, etc...

3. ⚠️ { 'vim.useCtrlKeys': true, 'vim.handleKeys': { '<C-d>': true, '<D-d>': true } }

Same as 2.

---

ℹ️ It seems like pressing Cmd+D from visual mode, then pressing c kind of work as expected, to the exception of that weird scroll back to the first selection.

For this to work, use the configuration of 3.

---

This is kind of annoying and is the only issue that prevents me from really enjoying this.

This could be mitigated by making cgn + . work (See #1955)

[pingshunhuangalex]

Still running into the same problem with the latest version. This is so annoying that I even feel like I'm on the edge of giving up Vim mode...

[rhys-vdw]

Yup, this one's still happening for me too. But the issue is still open so no reason to expect otherwise.

[redhat008]

I find ctrl+d for multiple selections in 0.10 is work.

[LPGhatguy]

Does anyone have a functional fix for this? I'm on Windows!

With useCtrlKeys: false, I've tried:

1. Not defining handleKeys
   • The current line gets unindented when I press ctrl+D, which doesn't make any sense.
2. Defining handleKeys as empty
   • Same as (1)
3. Defining handleKeys as { "<C-d>": false }
   • Works fine in visual mode
   • When pressing ctrl+D in insert mode, multiple cursors get made, but my selection gets cleared the first time I press ctrl+D
4. Defining handleKeys as { "<C-d>": true }
   • Same as (1)

The behavior in (3) is the closest, but it breaks the normal VS Code edit flow:

@jpoon You mentioned setting handleKeys to undefined -- what does that actually mean? If it isn't specified, it'll fall back to the default, and if it's set to empty, it seems like the setting will be merged with the default. It's JSON, so we can't actually set something to undefined!

[robclancy]

The one requirement for me to use any extension in vscode is that it doesn't fuck with ctrl+d. I use it so much. And I have just been over so many issues and still can't get it working.
I got it selecting what it should in visual mode if I config to true.

"vim.handleKeys": {
    "<C-d>": true
},

But this doesn't help me, I need to be in insert mode and it doesn't work in insert mode. And going back to insert mode removes the selection as well.

This is such a big issue that keeps getting posted over and over. Why not have a specific setting just for it that people can easily enable so they know what should happen. And then any reports of issues you know isn't configuration (which is still unclear) so you know when there are real issues.

I can live withoug vim. I can't live without an effective ctrl+d :(

What we all want seems to be the default behavior which you say is by setting undefined... which you can't do.

[niksosf]

in fact, even after remapping add selection to next find match to another key, say cmd+e, that same problem describe by @rhys-vdw 's gif still persists and this is on a clean install of vscode with only the vim plugin

[lzfee0227]

Try to use the trick instead before resolved:

1. useCtrlKeys": false
2. Move cursor to target text
3. Set vim to normal mode with esc
4. Select text with your mouse / touch pad
5. Use cmd / ctrl + d of vscode
6. Set vim to insert mode with i
7. move your cursor, it may works with multiple cursors (not multiple selections)

[chibicode]

This problem:

…is probably caused by

Vim/src/actions/commands/actions.ts

Lines 4154 to 4198 in c0d1e9e

	@RegisterAction
	class ActionOverrideCmdDInsert extends BaseCommand {
	modes = [ModeName.Insert];
	keys = ['<D-d>'];
	runsOnceForEveryCursor() {
	return false;
	}
	runsOnceForEachCountPrefix = true;
	public async exec(position: Position, vimState: VimState): Promise<VimState> {
	// Since editor.action.addSelectionToNextFindMatch uses the selection to
	// determine where to add a word, we need to do a hack and manually set the
	// selections to the word boundaries before we make the api call.
	vscode.window.activeTextEditor!.selections = vscode.window.activeTextEditor!.selections.map(
	(x, idx) => {
	const curPos = Position.FromVSCodePosition(x.active);
	if (idx === 0) {
	return new vscode.Selection(
	curPos.getWordLeft(false),
	curPos
	.getLeft()
	.getCurrentWordEnd(true)
	.getRight()
	);
	} else {
	// Since we're adding the selections ourselves, we need to make sure
	// that our selection is actually over what our original word is
	const matchWordPos = Position.FromVSCodePosition(
	vscode.window.activeTextEditor!.selections[0].active
	);
	const matchWordLength =
	matchWordPos
	.getLeft()
	.getCurrentWordEnd(true)
	.getRight().character - matchWordPos.getWordLeft(false).character;
	const wordBegin = curPos.getLeftByCount(matchWordLength);
	return new vscode.Selection(wordBegin, curPos);
	}
	}
	);
	await vscode.commands.executeCommand('editor.action.addSelectionToNextFindMatch');
	vimState.cursors = await getCursorsAfterSync();
	return vimState;
	}
	}

I traced back git blame, which pointed me to this issue and PR by @Chillee.

• Issue: <D-d> in insert mode doesn't work when the word isn't by itself #1749
• PR: 5004489

I saw that @Chillee posted this GIF, which seems pretty similar to the earlier GIF, and the above PR apparently fixed it.

So this seems like a regression?

[nidycai]

I am experiencing this problem today as well - but not intermittently, it happens every time the second selection is made.

me pressing cmd+d repeatedly on @extend☝️

I just have the same problem. 'C-d' can work in normal mode, but when I switch to insert mode, it just happens.

[karlhorky]

@J-Fields I guess this one should also get the area/multicursor label.

[Divide-By-0]

Is there a resolution for this? It seems as mentoined earlier, "vim.handleKeys": { "<C-d>": false } doesn't do the intended behavior to disable the shortcut. How else can I disable or remap this?

On the dev side, I'd imagine that changing "scroll halfway down" to ctrl+shift+d instead of ctrl+d would be a slight inconvenience to those who use that shortcut and a huge boon to everyone else, fixing the primary incompatibility of this plugin with VSCode.

[rhys-vdw]

@Divide-By-0 you can just disable all the vim stuff via the keymaps window like any other shortcut (accessible through command palette).