-
Notifications
You must be signed in to change notification settings - Fork 437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8330590: TextInputControl: previous word fails with Bhojpuri characters #1444
8330590: TextInputControl: previous word fails with Bhojpuri characters #1444
Conversation
👋 Welcome back angorya! A progress list of the required criteria for merging this PR into |
@andy-goryachev-oracle This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
@karthikpandelu Can you review this? We'll also need a review by a "R"eviewer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Validated the changes manually and using the unit tests.
The new unit test fails without the fix and passes with the fix provided in this PR as expected.
I have one query though, while moving from left to write by word (using option + RIGHT) for the same text, after the first word "Bhojpuri", it goes to the beginning of the Bhojpuri text and then to the end of the Bhojpuri text. But if it was all English text, then it directly goes to the end of the text and skips space. Is this expected?
I think it might be a bug - even though it's unclear how many words the text "𑂦𑂷𑂔𑂣𑂳𑂩𑂲" contains, I would not expect it to go to the beginning of that segment. I suspect the code in |
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.
|
@aghaisas would you please take a look at this also? |
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! |
I've created https://bugs.openjdk.org/browse/JDK-8331951 to deal with the "next word" function issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix looks good, providing minor comments.
if (ix < 0) { | ||
// should not happen | ||
return false; | ||
} else if (ix >= text.length()) { | ||
return false; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May be combine them into single if statement.
Or may be remove the checks as this is a private method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to keep one statement per line; the checks are needed here.
@@ -1743,4 +1742,15 @@ public int getAnchor() { | |||
} | |||
} | |||
|
|||
private static boolean isLetterOrDigit(String text, int ix, int len) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The len
variable is unused in this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed, thank you
/integrate |
@andy-goryachev-oracle Pushed as commit b5fe362. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with Character.isLetterOrDigit(int).
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1444/head:pull/1444
$ git checkout pull/1444
Update a local copy of the PR:
$ git checkout pull/1444
$ git pull https://git.openjdk.org/jfx.git pull/1444/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1444
View PR using the GUI difftool:
$ git pr show -t 1444
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1444.diff
Webrev
Link to Webrev Comment