RFR: 8330590: TextInputControl: previous word fails with Bhojpuri characters [v2]

[Andy Goryachev]

On Tue, 30 Apr 2024 17:11:25 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> Looking at the "next word" functionality across different applications on different platforms, it appears to be a wide variety of behaviors.
>> 
>> One vendor appears to be quite consistent - Microsoft.  Its word, word pad, notepad work exactly the same, with Word working the same across macOS and Win11.
>> 
>> JavaFX TextArea is inconsistent (by design) between macOS and Win11, but also is inconsistent with Swing's JTextArea.
>> 
>> If I were to fix the behavior (if we decide to fix the behavior of the nextWord function, that is), I would make it consistent with MS Word, but let's discuss.
>> 
>> For reference, here is the result of my testing.  Initially, the caret is placed at index 0 and the numbers in parentheses denote successive caret positions after ctrl-RIGHT (option-RIGHT) key presses.  An underline denotes a space, and a (nl) denotes a newline.
>> 
>> 
>> source
>> _english_english_eng:_end,_eng:_(nl)
>> (nl)
>> _eng
>> 
>> 
>> BreakIterator.getWordInstance()
>> _(1)english(2)_(3)english(4)_(5)eng(6):(7)_(8)end(9),(10)_(11)eng(12):(13)_(14)(nl)
>> (15)(nl)
>> (16)_(17)eng
>> 
>> 
>> text area (mac)
>> _english(1)_english(2)_eng(3):(4)_end(5),(6)_eng(7):(8)_(nl)
>> (9)(nl)
>> (10)_eng(11)
>> 
>> 
>> ms word (mac) 16.84 24041420 consistent with win11
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> (11)_(12)eng(13)
>> 
>> 
>> text edit (mac)
>> _english(1)_english(2)_eng(3):_end(4),_eng(5):_(nl)
>> (nl)
>> (nl)_eng(6)
>> 
>> 
>> chrome (mac) <div contenteditable=true>
>>  english(1)_english(2)_eng(3):(4)_end(5),(6)_eng(7):(8)_<br>
>> (9)<br>
>> _(10)eng(11)
>> 
>> 
>> eclipse (mac)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> (11)_(12)eng
>> 
>> 
>> JTextArea (mac)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (nl)
>> _(10)eng
>> 
>> 
>> ms word 365 ver 2302 build 16.0.16130.20942 (win 11)
>> same as notepad (win 11)
>> same as wordpad (win 11)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> (11)_(12)eng
>> 
>> 
>> TextArea (win11)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> _(11)eng
>
>> If I were to fix the behavior (if we decide to fix the behavior of the nextWord function, that is), I would make it consistent with MS Word, but let's discuss.
>> 
> The behaviour in MS word looks to be easy to understand and what we would expect. +1 for this.
> 
> Thanks @andy-goryachev-oracle for checking the behaviour and providing the details.

thank you @karthikpandelu for raising the question!

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2086058099