67
edits
User:Uri/Bidi editing: Difference between revisions
→Moving the caret
| Line 65: | Line 65: | ||
* The system determines the logical position associated with the visual position to the left (or right) of the current visual position. This step involves visual-to-logical mapping, which, as mentioned above, could be ambiguous. Note that visual-to-logical mapping is not covered by the IBM document. The code involved in achieving this task is quite elaborate and complicated. In addition to logical position, the system also determines the new value for the "hint". The new logical position and hint are stored in the selection object. | * The system determines the logical position associated with the visual position to the left (or right) of the current visual position. This step involves visual-to-logical mapping, which, as mentioned above, could be ambiguous. Note that visual-to-logical mapping is not covered by the IBM document. The code involved in achieving this task is quite elaborate and complicated. In addition to logical position, the system also determines the new value for the "hint". The new logical position and hint are stored in the selection object. | ||
* The system then uses he logical-to-visual mapping algorithm to map the new selection object back to a visual position, where the caret is displayed. | * The system then uses he logical-to-visual mapping algorithm to map the new selection object back to a visual position, where the caret is displayed. | ||
==Problems with the current implementation== | |||
The main problems with the current system should be evident from my description of the system above. I'll re-iterate them briefly: | |||
* The system does not always behave as the user expects: | |||
** In the case of deleting, when the caret is not adjacent to the to-be-deleted character, the system's solution is to not actually delete a character, but to move the caret (possibly a long distance!) to the position where the deletion ''would have'' taken place. This is likely ''not'' what the user expects. The user expects for a character visually adjacent to the caret to be deleted. | |||
** In the case of typing, the system (even when fully implemented) does not ''ensure'' that the typed character will apear at the location of the caret. The result could be confusing and even frustrating for the user. See [https://bugzilla.mozilla.org/show_bug.cgi?id=300004 bug 30004], and, specifically, the [https://bugzilla.mozilla.org/attachment.cgi?id=192975 second testcase] attached to it. | |||
* The process used by the system to perform visual functions (such as responding to right o left arrow keys), is extremely complicated, as it involves visual-to-logical mapping followed by logical-to-visual mapping, both of them being ambiguous, complex, tasks. All this is to achieve a simple result: moving the caret visually (e.g.) one place to the left. The complexity of this process makes its implementating code bug-prone and difficult to maintain, as the many dependencies of [https://bugzilla.mozilla.org/show_bug.cgi?id=207186 bug 207186] will attest. | |||
These problems, as I see it, are all a result of the system's need to maintain an internal "logical" representation of the caret position, while presenting a visual interface to the user. | |||