You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike system IMEs and CHIM/Mudim, AVIM looks at the current state of the input field at every keystroke; it doesn’t maintain a buffer. I’ve long been in favor of this approach and against maintaining a buffer, because it allows you to correct diacritics without retyping the word, and it avoids the entire class of stale buffer bugs. (It’s quite easy to run into these bugs in Mudim.) However, to implement #60, #81, #74, or #154, AVIM would need a buffer to avoid situations where the user’s intent can’t be reconstructed from the text field’s present value.
The solution would be to store two pieces of information as expando properties on the DOM text node being edited: the word immediately preceding the insertion point (the “buffer”) and an offset into the node (either to the start of the word or to the insertion point). For #154, the text node would also track whether the word in the buffer was being ignored.
AVIM would continue to consider the current state of the text field at each keypress, but this context could be supplemented by the buffer. To guard against staleness, the buffer can be compared to the node’s current text value. If it matches, the buffer can be used to continue the cancelation, rearrange the word based on the new keypress, etc. Otherwise, it would be cleared.
Since expando properties aren’t shared with Web content, they’re completely safe from manipulation by webpages.
The text was updated successfully, but these errors were encountered:
Unlike system IMEs and CHIM/Mudim, AVIM looks at the current state of the input field at every keystroke; it doesn’t maintain a buffer. I’ve long been in favor of this approach and against maintaining a buffer, because it allows you to correct diacritics without retyping the word, and it avoids the entire class of stale buffer bugs. (It’s quite easy to run into these bugs in Mudim.) However, to implement #60, #81, #74, or #154, AVIM would need a buffer to avoid situations where the user’s intent can’t be reconstructed from the text field’s present value.
The solution would be to store two pieces of information as expando properties on the DOM text node being edited: the word immediately preceding the insertion point (the “buffer”) and an offset into the node (either to the start of the word or to the insertion point). For #154, the text node would also track whether the word in the buffer was being ignored.
AVIM would continue to consider the current state of the text field at each keypress, but this context could be supplemented by the buffer. To guard against staleness, the buffer can be compared to the node’s current text value. If it matches, the buffer can be used to continue the cancelation, rearrange the word based on the new keypress, etc. Otherwise, it would be cleared.
Since expando properties aren’t shared with Web content, they’re completely safe from manipulation by webpages.
The text was updated successfully, but these errors were encountered: