Spaces aren't always treated as word breaks for `wordbreak_char_names` or `_paths`

Adding -_ as the value for the names option variant works to step between words with hyphens and underscores, however the Help documentation claims "A space is always treated as a word break" which is true for a blank (default) value, but not when it is customised.

| indicates the possible cursor positions in the string foo _ bar - baz foo_bar-baz foo_ bar -baz:

With no value for wordbreak_char_names:
|foo |_ |bar |- |baz |foo_bar-baz |foo_ |bar |-baz|.|txt|

When as -_:
|foo _ |bar - |baz |foo_|bar-|baz |foo_ |bar -|baz|.|txt|

In the second instance, one can no longer Ctrl+Left or Right to the right side of foo or bar as the (space) is being skipped over. Using (space)-_ as the value doesn't help either. The way DOpus is skipping between foo_bar-baz seems practical however.

I wanted to achieve the same for paths so I set wordbreak_char_paths to (space)-_ (I included a space because spaces aren't treated as word breaks by default):

With no value:
…\|foo _ bar - baz foo_bar-baz foo_ bar -baz\|…

When as (space)-_:
…\|foo _ |bar - |baz |foo_|bar-|baz |foo_ |bar -|baz\|…

Its result is the same possible cursor positions as an item in the File Display.

Customising one of these values shouldn't cost the ability to step to the right side of a word followed by a space.

Other than a possible fix, if the feature were to receive further refinement, the way VS Code handles stepping through strings covers all possible cursor positions but is dependant on the direction one is navigating from, and may serve as a good model to emulate.


- Directory Opus v12.23.1 Beta x64 Build 7710
- Microsoft Windows 10 v20H2 OS Build 19042.804