Fixes#7632.
If Caps Lock was on, rules that did not specify Caps Lock state were
not matched, for example:
```
+ [K_SLASH] > 'foo'
```
The truth table for matches is:
Event | Rule | Result
---------|-------------|-----------
NCAPS | 0 | match
NCAPS | CAPS | no match
NCAPS | NCAPS | match
CAPS | 0 | match
CAPS | CAPS | match
CAPS | NCAPS | no match
(Internally, Keyman for Mac currently maps 0 to NCAPS on the event for
simplicity.)
The fix is to ignore the Event Caps Lock state if the rule specifies
neither `CAPS` nor `NCAPS`. If the rule specifies either of these
state masks, then the Caps component of the state mask must match.
This change makes it possible to compile even when the updated
ibus version is not installed. Of course ordered output won't work
in that case, but at least it will compile and the rest of Keyman
will work.
Fixes#7774.
This reverts commit acab920de8.
I'm confused - now we're getting the same warning again - claiming
that `size_t` is defined as `long unsigned int` and so we have to
use `%lu`!? Is this related to the platform we're compiling on?
This time, the warning we get is when compiling for x86_64:
```
engine.c: In function ‘get_current_context_text’:
engine.c:224:15: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
224 | g_message("%s: current context is:%u:%lu:%s:", __FUNCTION__, km_kbp_context_length(context), buf_size, current_context_utf8);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| size_t {aka long unsigned int}
engine.c:224:40: note: format string is defined here
224 | g_message("%s: current context is:%u:%lu:%s:", __FUNCTION__, km_kbp_context_length(context), buf_size, current_context_utf8);
| ~^
| |
| unsigned int
| %lu
```
Reverting the previous fix for now.
Debian/lintian recommends to add a symbols file which allows to
check for API changes. The package build on Jenkins now has an
additional build step that will compare the API of the newly
built package with the committed symbols file and will fail the
build if the API changed and we didn't update the symbols file
yet. The current symbols file gets stored as build artifact, so
it can easily be copied from Jenkins.
During the build of the binary package this check is also run but
won't fail the build.
