feat(windows): core needs to preprocess U+000D U+000A to U+000A in context before any other processing
- Dominant language
- Pascal
- Stars
- 534
- Forks
- 143
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 113
Description
see EDIT:
I am anticipating that this will become a problem soon (encountered while working on the keyboard debugger).
I think this belongs under LDML keyboardprocessor. On Windows at least, `\r\n` should always be deleted as a block for K_BKSP.
We may need to special-case this, testing for the presence of this pair at the end of the context and requesting 2 back-deletions rather than 1.
(Note: I think this will become visible with the move from action queue to action struct in #10441, and become more obvious after #10415 is implemented.)
EDIT:
~~Principle -- Engine MUST preprocess context from compliant apps to convert \r\n to \n before supplying to Core, and then when emitting into compliant apps, do the inverse, \n to \r\n. Note the Keyman Developer debugger also needs to consider doing this.~~
See PR #10697 Which implements the proposed algorithm in the engine but we want it in the core.
We track what the engine gives the core input context, and give the same pattern back. This then covers all combinations of `\r` `\n` `\r\n`.
Test cases will be needed around buffer limits (if the algorithm causes truncation).
Also testing the developer debugger vs the built and installed keyboard should be tested to make the developer debugger exhibits the same behaviour.
Testing on each platform also (linux, windows macos)
Contributor guide
Assessment
This issue has not been assessed yet.