Fixes#5488.
This updates Keyman Core, corresponding tests, and Keyman Engine for
Linux to support deletion of markers through an action, ensuring that
the action queue does not desynchronize with the context.
Adds some tests for Keyman Core for debugging, verifying contents of
the action list after every keystroke in the test.
Also refactors some of the test helper files to make it easier to
diagnose failing tests and share helper functions.
Adds an action_index to each debug event (not all debug events
need it). This allows the debugger to partially execute a rule
including the possibility of multiple updates to context.
Adds debug events to the kmx processor and corresponding unit tests.
This corresponds largely to the way that keyman32 emits debug events,
but with one key change: debug events in keyman32 are processed
synchronously, whereas in Keyman Core, the full set of debug events will
be returned alongside the final action list for the key event.
Given this difference, there will likely need to be some more data
returned in individual debug events, specifically around intermediate
context manipulation, as required for step-by-step debugging. However,
that will come in a subsequent PR.
Part of #5013.
Adds all the debug infrastructure:
* public API headers
* public API implementation classes and functions
* basic unit tests
* helper classes for recording debug events
* minimal implementation of kmx-specific debug event signalling --
just BEGIN and END events.
* tangential: unit test assertion macros and coloured output
Relates to #5069.
This establishes a baseline Rust build environment and linkage with
common/core/desktop.
This includes:
* build script build.sh which handles builds on Windows, macOS, *nix,
with multiple targets on Windows only at present (M1 on mac to come
when we do the mac integration work.)
* a mock rust processor with a very stubbed-out implementation
* bare bones interface between Rust library and C++ code
* unit tests on Rust and integration tests on C++ side to test the
linkage between the libraries.
This should deliver a set of libraries that can be linked into our
target applications. For ease of deployment, it may be best to make
these static libraries, but I haven't made that decision at this point.
