[Webkit-unassigned] [Bug 65277] Make functions to find word boundaries more flexible

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=65277





--- Comment #56 from Van Lam <vanlam at google.com>  2011-08-29 10:28:59 PST ---
(In reply to comment #55)
> Some comments:
> 1. It's important to know not just what function currently does, but what it's supposed to do. There are two ways to describe that in function name - either by telling what exactly it does, or when exactly it's supposed to be called.
> 2. nextWordBoundaryBeforeWord(VisiblePosition) looks as if it returned next word boundary before word that contained the VisiblePosition, which makes no sense.
> 3. You changed one of the test cases, so I'm unsure what happens for "test   |     test test".
> 4. You are saying that there are platform differences allowed in the results. What differences are OK? Mac version of findNextWordFromIndex() isn't based on ICU, and I don't know how different it can be. In particular, how will we avoid issues like bug 65898 going forward?
> 5. If implementing Windows style alt-arrow movement is the goal, perhaps the code should make this explicit. Also, being unable to move across paragraphs is incorrect for this use case.

1) I should make it explicit that these functions work within a single box.

2) How's wordBoundaryBeforeNextWord? I think this is more clear.

3) Ah, I overlooked this test case. Here it is: test   |     test test -> test        |test test

4) As far as I know every platform's findNextWordFromIndex returns the word boundary after the next word; the differences that will affect this function are which special non-alphanumeric characters get treated as parts of words. As for bug 65898, isn't this a problem that should be fixed within findWordBoundary and findNextWordFromIndex? Right now "foo bar _baz_" breaks the logical word movement as well (alt left arrow after "_baz_").

5) The ultimate goal is to implement the Mac style alt-arrow movement (as the Windows version is already implemented); to do this we (Xiaomei and I) planned to return the correct word break based on box directionality, block directionality, movement direction, and editing behavior. Having these two functions would simplify the code a lot. I should point out that these two functions would mainly be used as helper functions within visual word movement code; in the end alt-arrow will move across paragraphs.

Thanks for your feedback!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.