Word navigation (ctrl+left/right): do not stop before and after every space
It seems that in recent version of SmartGit, word navigation stops before and after every space.
This means that if you have a commit message "Added level 2" with the caret after 2, you need to press Ctrl+Left 3 times to go before "level".
I would rather have the caret skip any space before the next word in the pressed direction, as in other editors, so you press Ctrl+Left/Right as many times as there are words to skip.
In general, such editors also skip multiple spaces before a word. Although YMMV and you may want not to skip if there are 2+ spaces or more. Personally I'd just skip them and let the user go back with Ctrl+Left then Ctrl+Right, or reversely.
Generally speaking, if the user still wants to stop at the other boundary of the word, they can always play with Left/Right and Ctrl+Left/Right for an extra adjustment, it shouldn't take more than one extra input.
Customer support service by UserEcho
Yeah, noticed this change in behavior recently. No other editor I use behaves this way, and it makes it quite cumbersome for keyboard-oriented users. Wish the old behavior was restored, or there was a setting to change how ctrl+left/right behaves.
SmartGit 23.1 build 20112 will contain the low-level property
styledtext.useOwnWordBoundaryDetection to disable our changes and use the system default.
Great, it works on Linux Ubuntu / Unity desktop to not stop at spaces, and probably other OSes since they use the same convention in other text editors!
But after more testing I understood why the new boundary detection was added: my system default stops at both hyphens and underscores, which is useful when editing subwords but very slow when navigating across a commit message filled with snake_case variable names.
So to get the best of both worlds, I'd either need:
- more options to decide atomically if hyphen - and underscore _ are boundaries
- commands with customisable shortcuts to navigate to previous/next subword (e.g. ctrl+alt+left, ctrl+alt+right - maybe not great with some window managers where it's mapped to snapping windows left/right, but alt+left/right was already taken - anyway, the defaults could be left empty as long as it's customisable)
That would be for another issue though, the space stop was what was taking me the most time. I'll open another issue for underscores.
I opened to new requests:
Specific word boundary settings for hyphen & underscore detection https://smartgit.userecho.com/communities/1/topics/1685-specific-word-boundary-settings-for-hyphen-underscore-detection
Subword navigation shortcuts (e.g. Ctrl+Alt+Left/Right)
https://smartgit.userecho.com/communities/1/topics/1686-subword-navigation-shortcuts-eg-ctrlaltleftright
Please give the low-level property styledtext.wordCaretMovementType in SmartGit 24.1 preview a try.
Thanks, 24.1 > styledtext.wordCaretMovementType seems to replace the styledtext.useOwnWordBoundaryDetection entirely but the enum offers more options. "system" is the equivalent of styledtext.useOwnWordBoundaryDetection = true and has the issues I mentioned on Ubuntu, while win, mac and gtk behave as I wanted, one pause per space and skipping underscores.
Finally, word-boundaries also stops once per space but also stops at underscores, like system, but it's good to have a system-independent option for people who reliably want to pause at underscores.
So I'll go with win/mac/gtk, good for 99% of my usage, and I'll be waiting for Subword navigation shortcut feature (link in my previous post).
Note: I'm actually the OP but switched account without noticing at some point.
Correction: "system" is the equivalent of styledtext.useOwnWordBoundaryDetection = false
> word-boundaries also stops once per space but also stops at underscores, like system
Sorry, I don't understand this. Could you please explain on an example?
Well, it's exactly the same issue as when setting `styledtext.useOwnWordBoundaryDetection = false` before.
If I start here:
|a_b c_d
and I repeatedly press Ctrl+Right, I go there:
a|_b c_d
a_b| c_d
a_b c|_d
a_b c_d|
which is quite slow.
For which setting of styledtext.wordCaretMovementType you are seeing this behavior?
... "system", it's what I said in the post from June 3.
While win, mac and gtk are OK.
But it's not really an issue, I just use gtk now.
That is by design. System leaves everything to the system/default SWT implementation. Only the other options are using our code.