editor.expandSelection does not respect editor.wordSeparators setting

[focusaurus]

About Info:

Version: 1.41.0
Commit: 9579eda04fdb3a9bba2750f15193e5fafe16b959
Date: 2019-12-11T18:32:17.711Z
Electron: 6.1.5
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Linux x64 4.15.0-70-generic

The selection behavior varies between selecting words with a mouse double-click versus selecting with a command or hotkey. A mouse double-click respects the editor.wordSeparators setting. The built-in expandSelection does not. (Aside: the craig-johnston.selectword extension.selectWord command also does not repsect editor.wordSeparators). Other commands do properly respect the setting such as deleteWordLeft and deleteWordRight

My specific use case examples when clicking just after the "k" in "kebab-case" or issuing a command palette command with the cursor just after the "k". What I'm looking for here is a way to select an entire word via the keyboard that respects the editor.wordSeparators setting and despite a significant search of related extensions, I cannot find a way to do this with either core functionality or an extension.

My settings include:

{
  "editor.wordSeparators": "`~!@#$%^&*()=+[{]}\\|;:'\",.<>/?",
  "[clojure]": {
    "editor.wordSeparators": "`~!@#$%^&*()=+[{]}\\|;:'\",.<>/?"
  }
}

language	mouse doubleclick	expandSelection	selectWord
file.txt	kebab-case	kebab	kebab
file.md	kebab-case	kebab	kebab
file.clj	kebab-case	kebab	kebab

I have asked about this problem already on stackoverflow and the VS Code subreddit and in the craig-johnston.selectWord extension

Sadly, hitting expandSelection twice selects too little the first time and too much the second time.

Possibly related prior issue and discussion 8233 getWordRangeAtPosition does not respect word separator settings

[alexdima]

• VS Code has for each file two distinct "word definitions": one provided by the programming language and one derived via the effective value of "editor.wordSeparators".
• The builtin "Expand Selection" command is normally using the ranges provided to it by a language server, so it is programming language specific. In case a language server does not register such a provider, I think it uses the current word as defined by the language, and then expands to encompassing brackets. Since the command respects what the language server provides, it is outside of our control to tweak it to respect editor.wordSeparators.
• There is another widely used action, "Add Selection To Next Find Match" at Ctrl+D, which will expand the selection to the current word. This action is also currently using the word definition provided by the programming language. We plan to move this one to use editor.wordSeparators.

I therefore suggest we continue tracking this in #15774 , and once #15774 is done, you will be able to use Ctrl+D to expand to current word under cursor.