previousWord and NonDigits includes the precending whitespace

[Ambior]

Hi Tomas,

if a word starts with a number, the selection after previousWord() includes the precending whitespace.
The function NavigationActions.previousWord() calls !Character.isLetter(text.charAt(pos)) and moves to the precending position.
I supose this is a bug?!

greetings Roel.

[TomasMikula]

I changed it to always skip two word boundaries.

[Ambior]

Hi Tomas,

thanks for the fast reaction. I wonder about the last call to wordBreakIterator.previous(). This includes the previous whitespace in the selection. Is this intended to be so?

greeting
Roel

[TomasMikula]

It has the property that if the caret is at the end of a word, it jumps to the end of the previous word, and if the caret is at the beginning of a word, it jumps to the beginning of the previous word. So you can say it is consistent in this way. Always jumping to the beginning of a word is also an option, consistent in a different way. I don't know which one is better.

When I Ctrl+Left/Ctrl+Right navigate in any text editor, 50% of the time I have to adjust the caret position by one space to get it where I wanted, no matter how the editor implements word navigation (because 50% of the time I want to go to the end of the word and 50% of the time to the beginning of the word). Therefore, I didn't think too hard what the exact behavior should be, as long as it's close to what one expects.

Can this be a setting maybe? setNavigation() method for example?
On 09/07/2014 6:04 AM, TomasMikula wrote:

It has the property that if the caret is at the end of a word, it
jumps to the end of the previous word, and if the caret is at the
beginning of a word, it jumps to the beginning of the previous word.
So you can say it is consistent in this way. Always jumping to the
beginning of a word is also an option, consistent in a different way.
I don't know which one is better.

When I Ctrl+Left/Ctrl+Right navigate in any text editor, 50% of the
time I have to adjust the caret position by one space to get it where
I wanted, no matter how the editor implements word navigation (because
50% of the time I want to go to the end of the word and 50% of the
time to the beginning of the word).

—
Reply to this email directly or view it on GitHub
#69 (comment).

[TomasMikula]

I don't want to overcomplicate such a trivial thing. If someone really wants to override the default behavior, they can register an event filter and implement the navigation themselves.

yea make sense :)
On 09/07/2014 11:44 AM, TomasMikula wrote:

I don't want to overcomplicate such a trivial thing. If someone really
wants to override the default behavior, they can register an event
filter and implement the navigation themselves.

—
Reply to this email directly or view it on GitHub
#69 (comment).