ctrl+d currently uses the word definition as it comes from the language configuration.

We could consider changing ctrl+d to use the word definition provided in editor.wordSeparators.

@alexandrudima Can extensions change the word definitions? Installing sublime keymap helped me greatly in transitioning to vs code, I wonder if this could be added to a How you're used to sublime behaving package :)

We have two kinds of word definitions.

1. editor.wordSeparators

This is a configuration setting with the default of `~!@#$%^&*()-=+[{]}\\|;:'\",.<>/?. AFAIK extensions are not supposed to change defaults for built-in settings, but I'm not sure anymore. Maybe @sandy081 knows ?

This is currently mostly used when doing word navigation or double clicking or in the match whole words in the find widget.

2. a language configuration wordDefinition

This comes in via a language configuration (driven entirely by extensions that contribute languages to VS Code). Most languages contribute it via a language configuration file, but it is possible to overwrite the settings via languages.setLanguageConfiguration in the API.

This is used in very many places, including in Ctrl+D today.

That being said, it is not a really good idea to mess with any of those from an extension.

e.g. the json extension sets a certain word definition for json and expects that to be the one used by the suggestions. If another one comes in, things might not go so well. i.e. changing the word definition for a language might break in subtle ways various language features.

This issue is about if we should move Ctrl+D over to use editor.wordSeparators, as Ctrl+D is perhaps more like word navigation than like suggestions, debug variables, etc.

AFAIK extensions are not supposed to change defaults for built-in settings, but I'm not sure anymore. Maybe @sandy081 knows ?

Yes, an extension cannot register a built in configuartion.

Just wanted to chime in: this little thing is really bugging me. I recently tried transitioning from PHPStorm and am delighted so far with the result.

But: Ctrl+D not honoring the wordsSeparators is that one thing which I always trip about.

Would it be possible to have a config-switch to choose which word definitions should be used?

I would also like to say thank you for this amazing piece of software, I really like it!

Bump. It's crazy how much this seemingly small issue hurts me. I depend on ctrl+d to select a word in the way I choose. I'd also love to see settings for honoring camelCase word splitting, but I can live without it.

Bump. Just dug through several ctrl+d / cmd+d threads to find this.

In Atom, I could override my nonWordCharacters for every type of file. This was something you could set in the settings for each language package, or from your config file.

Is there an option that exists to achieve this that I'm not finding? (One that doesn't potentially break other functionality like noted above)

Personally, I just want my hotkeys to manipulate/traverse/select text in a consistent pattern for any file type.

This is so jarring.
How am I to know what every language deems a word separator? The editor really should be consistent in this respect. Ctrl + D is normally a huge time saver, however with little inconsistencies across different languages in this behaviour I'm wasting time not only manually selecting text with the mouse, but time researching a fix for something that's driving me crazy.

At the very least I feel this should be an option, but should really be changed by default to act the same way as a double click on a word would.

Is the change here that Ctrl+D will use editor.wordSeparators instead of the language configured word separators? Verified that, but I'm not sure it's a good change. Word separators change based on language, in Lisp I want ? to be included in my words, in TS I don't. This seems to be strictly reducing the effectiveness of language configured word separators.

This further breaks Cmd+D in TS/JS, as the default editor.wordSeparators includes $, but in TS/JS that's not a word separator. In Stable pressing Cmd+D in my$Var will select the entire var, but now in insiders it won't.

Is the change here that Ctrl+D will use editor.wordSeparators instead of the language configured word separators? Verified that, but I'm not sure it's a good change. Word separators change based on language, in Lisp I want ? to be included in my words, in TS I don't. This seems to be strictly reducing the effectiveness of language configured word separators.

Configure per-language settings like so:

    /* Remove $ for JavaScript, PHP, and PowerShell.  */
    "[javascript]": {
        "editor.wordSeparators": "`~!@#%^&*()-=+[{]}\\|;:'\",.<>/?"
    },
    "[php]": {
        "editor.wordSeparators": "`~!@#%^&*()-=+[{]}\\|;:'\",.<>/?"
    },
    "[powershell]": {
        "editor.wordSeparators": "`~!@#%^&*()-=+[{]}\\|;:'\",.<>/?"
    },
    /* Remove $ and - */
    "[scss]": {
        "editor.wordSeparators": "`~!@#%^&*()=+[{]}\\|;:'\",.<>/?"
    }

This may depend on your use-casefor CTRL+D. In my opinion this is not a "language" feature, but an "editor" one, and so I have the opposite opinion to you :|

@mbomb007

Configure per-language settings like so

I understand that I am able to configure this myself, but the whole point of language extensions is that they configure it for me. And sure the language extension could contribute that setting, but they already contribute word boundaries, why are we making them do it twice?

@rockfruit

This may depend on your use-casefor CTRL+D. In my opinion this is not a "language" feature, but an "editor" one, and so I have the opposite opinion to you :|

I think thats a good argument to make this a setting, preferably disabled by default as this will affect many peoples workflows, and only ~4 have explicitly requested it.

I like the fact that I can change the behavior of double-clicking on some text per-language by changing the word boundaries. Idk why PHP has $ as a boundary character by default. I don't particularly care if Ctrl+D does the same or not, but I think it makes sense for it to respect any settings changes made and behave the same as double-clicking.

@mbomb007

I like the fact that I can change the behavior of double-clicking on some text per-language by changing the word boundaries. I don't particularly care if Ctrl+D does the same or not, but I think it makes sense for it to respect any settings changes made.

If you're double-clicking text in the IDE, you're doing it very differently to how I do 😁

I (and possibly three other people) do care. It's the primary reason that I have been literally unable to use vscode the last times that I have attempted to. It's like having someone move the "[" and "]" keys (looking at you, ergodox) - finger memory of many years must be retrained, and it calls into question the worthiness of the effort.

It's behaviour is expected to be predictable in an instant, without thinking "Oh wait, am I in PHP right now? What am I doing in PHP? Why? Why even any of this suffering and uncertainty? What's the point?"

If I do need to select a chunk of text like asd$jkl#three then I can always know to select it before hitting CTRL+D, without wondering if vscode has some idea about files that end in ".whatever".

Anyway as @JacksonKearl suggests, a setting is a really good idea, especially since at this moment code exists for doing it both ways! IDEs should have more settings than any other software in the world.

The concept of a "word" is different per language. If you want it to behave the same way no matter the language, you don't have to change "editor.wordSeparators".

However this gets resolved, it'd be greatly appreciated if someone could do a write-up on how a user should go about controlling this, and what all is affected.

It's especially frustrating to me when packages add their own word separators. Personally, I'd prefer to be able to force all my word separators to be consistent, as I think contextual changes based on different language types is confusing when it comes to keyboard navigation and selecting text, though I can see where many users would find it handy. For me, it'd be nice if I could force my Editor: Word Separators setting to apply regardless of any language type's settings.

I'm still confused why double clicking and using cmd+d (ctrl+d for non mac) selects different text in certain cases.

@JacksonKearl This is intentional, as in it was a feature request and now it is closed with an intentional change.

The background is that word definitions from languages are severely broken sometimes, as they are optimized for intellisense, where the word definition is very important. For example Ctrl+D in JSON is useless before this change because of JSON's word definition.

This change aligns Ctrl+D with the other places where editor.wordSeparators is used: in the find widget and in word navigation commands.

@alexdima Do you have a link to any documentation on this or an idea on why things would seem to be behaving inconsistently?

Simple example: .classname {
cmd+d from the middle of the text selects .classname with the leading dot in an scss file
double clicking the middle of the text selects only classname

This is just one of many inconsistencies I've come across that are frustrating.

@jsunsawyer I think we are in agreement? 😄

@alexdima Hmm, I think I'm confused on word definitions then. Is this not something that can be edited? Are you saying that we're stuck with inconsistencies because certain languages have word definitions that supersede wordseparators settings?

Here is what will change in the upcoming 1.44 and is available for you to try in Insiders since about 1 month: Ctrl+D will now select words based on the setting editor.wordSeparators and no longer based on the language configuration. That setting is also respected when double clicking, when doing ctrl+left / ctrl+right / ctrl+backspace / etc.