Select without entering visual mode

I hope to implement Helix's selecting style:

• When you press 'w' you select till a word end; when you press 'w' again, you will cancel the current selection and select the next word.
• When you press 'v' and enter visual mode, you will select multiple words as you press 'w's.

This seems not possible in modal-keys, since any selection would enter visual mode. Is it possible to only enter visual mode explicitly?

Thanks!

1.) you can do whatever you want, since you can always export the keybindings "ModalKeys: Export a preset for keybindings" and make whatever changes you want.

2.) If I understand your description, this is exactly how my Larkin keymap works. You can press space to explicitly enter selection mode. Then, w should extend the selection by a word. Normally, word motions select individual words with each key press. To use the Larkin keybindings, use the "Import preset keybindings" command to use the Built-in: Larkin keybindings. Then hit the space bar. You should now be in a mode where moving by word will extend the selection.

Oh, hold on! That's actually how Larkin.js used to work. But I eventually decided I preferred another behavior.

Let me check on the old version of that file and see if I can dig up the settings. They're relatively simple to do. You may be able to figure it out yourself by looking at the commands it uses (found in https://github.com/haberdashPI/vscode-selection-utilities)

Thanks for your reply! vscode-selection-utilities seems useful. I would check it later when I found some spare time. I am currently using another extension Dance as a workaround, which however depends on the built-in keymap mechanism of VSCode and is sightly troublesome(though their modal setting is indeed more flexible, there can be arbitrary modes and modes will only be switched explicitly)...

I've heard about Dance, it seems pretty good. I built this extension when it was in a much less evolved state, but I've set up a lot of additional features here that I want to keep, so still favor my own extension.

though their modal setting is indeed more flexible, there can be arbitrary modes and modes will only be switched explicitly

Can you elaborate on this? ModalKeys also has arbitrary modes and you can switch between them using explicit commands. I'm curious what Dance can do that you are unable to do in ModalKeys. Perhaps my documentation just isn't explicit enough about the ability to define arbitrary modes?

If you wanted to implement the word motion you describe in the OP, it would look something like this:

"w": { "selection-utilities.moveBy": { 
    unit: "word",    
    boundary: "both", 
    selectWhole: "__mode == 'normal'",
    value: ' (__count || 1)' } 
}

In trying to figure out the actionable item here, I think what is needed is some additional document. Perhaps a list of simple examples of behaviors you might want to implement, and how to implement them.

Sorry for my late response. I just finished a paper submission and finally found some spare time to try your vscode-selection-utilities.

It indeed implements the word motion I described, but it still enters visual mode. So if I press w then arrow keys, I will get an extended selection while I expect it just moves the cursor like Helix.

I tried browsing the code, and I found those lines:

https://github.com/haberdashPI/vscode-modal-keys/blob/872500cedacc15ad3267654d541479f88fd83867/src/commands.ts#L68-L71

https://github.com/haberdashPI/vscode-modal-keys/blob/872500cedacc15ad3267654d541479f88fd83867/src/commands.ts#L495-L497

I wonder if it is possible to have a "explicit visual mode" setting option. When it is enabled, the visual mode switching only happens at explicit "modalkeys.enableSelection" call and ignores the editor selection status. In addition, entering normal mode should not cancel curent selection when the option is enabled.

This modification should not be complex, and I can make a PR if you think the option is ok.

Can you elaborate on this? ModalKeys also has arbitrary modes and you can switch between them using explicit commands.

I didn't realize there is a "modalkeys.enterMode" command. I just read the package.json and your larkin presets and found it. There should be no difference about arbitrary modes.

I'm totally open to PRs!

I wonder if it is possible to have a "explicit visual mode" setting option. When it is enabled, the visual mode switching only happens at explicit "modalkeys.enableSelection" call and ignores the editor selection status. In addition, entering normal mode should not cancel curent selection when the option is enabled.

Can you elaborate on this? I think what you want is something akin to visual mode that doesn't follow the selection status. I don't think this requires a PR. The behavior of visual mode to follow the selection status is the only thing that makes it different from other modes.

So I think you could accomplish what you want by creating a new mode. Call it "explicit-visual" or something. Define all keybindings to be the same for both visual and normal mode. You can do this as follows: an explicit normal mdoe binding ({"normal::j": {...}}) would become a binding for both modes ({"normal|visual::j": {...}}), or, if you don't have explicit normal mode bindings you can just use {"j":{...}}, and it will define the binding as the default for all modes (and just don't define an explicit "visual" mode binding for anything). Then define keybindings for your "explicit-visual" mode that correspond to the visual-mode keybindings you want. Doesn't that accomplish what you want?

For example you could modify larkin.js by find-replacing all instances of visual:: with explicit-visual::.

So I think you could accomplish what you want by creating a new mode. Call it "explicit-visual" or something. Define all keybindings to be the same for both visual and normal mode.

This seems to work in general. Thanks!

The only problem left is that I need an alternative normal mode too, to escape from the default behavior of canceling current selection when you switch to normal mode. I can remap escape key to return to my normal mode, but I cannot have it as the default mode.

There is currently an option modalkeys.startInNormalMode related to the default mode. But it is not flexible enough to set to a custom mode. In fact, I cannot use it to make insert the default mode either. There seems to be a bug in the current implementation. I will see if I can make a PR about configurable default mode tomorrow.

Ah I see. I wonder if the right design here is to allow additional commands to be run when switching to any given mode. I'm okay with a PR that sets a configuration value to turn the current behavior off and on, but long term seems like a generic solution would be best. (And not much harder to implement).

Ah I see. I wonder if the right design here is to allow additional commands to be run when switching to any given mode. I'm okay with a PR that sets a configuration value to turn the current behavior off and on, but long term seems like a generic solution would be best. (And not much harder to implement).

By "configurable default mode" I mean replacing the current modalkeys.startInNormalMode with a modalkeys.startInMode: string to allow the editor starts in arbitrary, not the explicit visual behavior mentioned above. Even if the generic solution is implemented, this would still be helpful.

About the generic solution, I totally agree it's better. I think the key point is to enhance the ability of custom modes so that the current behavior of predefined modes can be implemented in the presets by the users. And finally, there is no need for predefined modes.

Agreed, the long term ideal is for all modes to have a uniform means of specification (but with defaults that are consistent with user expectations coming from other modal editors).