We've just had an interesting discussion with rxi about how should ctrl+right(next-word-boundary) and ctrl+left (previous-word-boundary) work in code editors. Here are some musings from that discussion.

What others do

I'll be using | to denote where caret would end up in given direction.

Sublime does this:

VSCode does this:

Try it yourself and with every ctrl+right try to guess where the caret would end up. I had quite a bad score. I had to do it step by step to actually construct the examples. Yes, it's 7 steps, but if I can't predict I will most likely overshoot and will have to compensate by additional hits.

I remember times in UX where people were using "number of clicks to get to goal" as the main metric. Number of steps is irrelevant if the user feels lost most of the route. It's better to have more steps but have user reassured that he's on right path. That way they don't even have to remember "where to click" he can simply use the same logic they used before.

I feel this is the same problem: It's less important how many steps I have to do if I know what the next step is.

Both implementations probably started somewhere with Unicode word-boundary algorithm, so trying to mimic classic word-processors. Code is different, a "word" in code is a token. Tokens use symbol characters for brevity, but they bear the same meaning as a word would:

Void pointer alloc start arguments intptr_t size end arguments start block.

My approach

My approach is always very granular and it stops at every start and end of lexer-provided token. For the same example it would do this (regardless of direction):

It simply is exactly where you'd see the syntax highlighting color be changed, so it's very easy to predict. 11 steps is double of what other editors do.

Improvements

There are two things that can improve the approach: