Fixes#4591.
I fixed incxstr in 4 places:
1. Common/Core: kmx_xstring.cpp
2. Engine: xstring.cpp
3. Test project importkeyboard importkeyboard.cpp
4. Test project m-to-p m-to-p.cpp
I updated mcompile to remove its own copy of incxstr (identical to that
in xstring.cpp) to reduce WETness but opted not to do so for the test
apps, which are pretty much throwaway anyway.
I note that there is more work we could do here; we need to check every
character as we increment so we don't miss a `U+0000` end of string with
malformed data. But I would like to tackle that as a separate job at
some point in the future after Core integration.
Fixes#2241.
The `&CasedKeys` system store is a compiler feature that reduces the
repetitive nature of keyboard rules for `CAPS` and `NCAPS`. The
`&CasedKeys` system store defines a list of virtual keys for which
'normal' Caps Lock rules apply. This store has no default value, for
backward compatibility.
Once this store is defined, then you can define just the unshifted and
shifted versions of a rule, and Keyman Developer will synthesize the
`CAPS` and `NCAPS` versions of the rule. For example, you may have the
following rules:
```
store(&CasedKeys) [K_A]
+ [K_A] > 'α'
+ [SHIFT K_A] > 'Α'
```
These would be replaced by the compiler with:
```
store(&CasedKeys) [K_A]
+ [NCAPS K_A] > 'α'
+ [SHIFT CAPS K_A] > 'α'
+ [CAPS K_A] > 'Α'
+ [SHIFT NCAPS K_A] > 'Α'
```
You can also use this functionality with characters in the key part of
the rule:
```
store(&CasedKeys) 'a'..'c'
+ 'a' > 'α'
+ 'A' > 'Α'
```
and the compiled expansion would be similar:
```
store(&CasedKeys) [K_A] [K_B] [K_C]
+ [NCAPS K_A] > 'α'
+ [SHIFT CAPS K_A] > 'α'
+ [CAPS K_A] > 'Α'
+ [SHIFT NCAPS K_A] > 'Α'
```
This feature is backwardly compatible with Keyman 6.0, as it is entirely
implemented in the compiler.
This feature is not compatible with mnemonic layouts, and the keys
defined in the `&CasedKeys` store must be the unshifted base keys as
found on a US English keyboard, or you can use ISO9995 identifiers if
you prefer.
If you define a rule where you specify either `NCAPS` or `CAPS`, for a
key found in the store, then no change will be made to that rule. You
can also continue to define rules which use `NCAPS` or `CAPS` for keys
not found in the store.
As a side-benefit, this allows the visual designer to be used and
support Caps Lock, although at this stage, the `&CasedKeys` store is not
surfaced in the visual designer.
Relates to #2241.
Range expansions are a new language feature that reduce verbosity in
Keyman Keyboard Language (.kmn) files by making it possible to collapse
sequential ranges with a new `..` operator. It is envisioned that these
will be used primarily in stores.
Two kinds of expansions are available: character ranges, and virtual key
ranges.
The syntax is:
```
char '..' char
vkey '..' vkey
```
Where the `char` terminator is a single normal character, and the `vkey`
terminator is a single virtual key. `outs` is permissible for
terminators but no other statement is allowed. Whitespace is per normal
Keyman keyboard language syntax.
Character ranges will replace the range with the set of characters
between the terminators, based on the Unicode value of the terminators.
Examples:
```
store(alphabet) 'a' .. 'z'
store(alpha_not_bq) 'ac'..'pr'..'z'
store(capitals) U+0041 .. U+005A
```
Virtual key ranges work in a similar fashion, but with virtual keys. The
starting and terminating virtual key must have the same shift state.
This will be most useful for character and numeric virtual keys, as the
ranges are based on the numeric value of the virtual key as defined by
Windows, not its position on the keyboard.
Examples:
```
store(alphakeys) [K_A] .. [K_Z]
store(numkeys) [K_0] .. [K_9]
```
Ranges must be positive, that is, you cannot use `'z' .. 'a'`.
While this expansion is not expected to be very useful in rules, it is
still permitted. `context()` and other offsets are calculated on the
expanded form, not the collapsed form. Similarly, `any()`/`index()`
offsets are calculated on the expanded form.
'a' .. 'z' > context(3) c this produces 'c', not 'z'
Because ranges are expanded at compile time, ranges that are overly
long will result in an error, so you cannot use, for example:
```
store(AllUnicode) U+0020 .. U+10FFFF
```
The precise maximum length of a range is dependent on the context where
it is used.
The changes are entirely compiler-based; no change is made to the .kmx
file format or to the Keyman apps.
Fixes#4423.
Using a named character constant with a store name that included
characters outside ascii could cause kmcmpdll to crash with an assertion
failure.
This fix allows store names defined in the .kmn file to use characters
outside ascii.
Note that more work needs to be done on which characters are acceptable
to use, as this is somewhat implementation-specific according to the C++
specification for `iswalpha`.
Added a test case to verify various named code constant examples.
Also removes dead code for `IsCJKUnifiedIdeograph` as this was never
used and somewhat pointless in any case.
NamedCodeConstants.cpp could stand to be rewritten using `std::map` or
equivalent. Current implementation is pretty icky.
Fixes#4280.
Adds checks to verify that `if()`, `platform()`, `baselayout()` and
`nul` are at the start of the context in the appropriate order.
Adds unit tests to validate these checks.
These are conditions that have been present in earlier versions of
Keyman but not enforced until now. Keyboards that do not meet these
conditions would not work correctly in all circumstances and should be
updated to meet the requirements.
An alternative would have been to reorder the context string but that is
much more complex as manipulation would also have been required for the
output string. The enforced order is logical and reduces confusion in
any case.
Updated documentation coming along shortly.
DUnitX by default does case-insensitive string equality assertions, and
we don't really want to make that assumption.
There was one minor fail uncovered in Keyman.System.UILanguageManager as
a result of this -- it now returns a matching entry as found in the
list of UI languages, rather than the input, to get same case as the UI
language list entry.
Thank you @ermshiperete.
Fixes#4264.
The Android strings.xml format that we now use with Keyman Desktop has a
number of escapes that must be supported in order for text strings to be
rendered correctly, including: @, ?, ', ". Furthermore, positional
parameters have a slightly different format which we should transform on
load.
This change includes a unit test androidstringtokeymanlocalestring.
Fixes#3863.
This adds the new `*RTLEnter*` and other tags introduced in #3851 to
the touch layout editor, and adds validation for use in 14.0 keyboards.
Due to a limitation in the compiler architecture, use of these tags
will not trigger the automatic keyboard versioning functionality; the
keyboard developer must explicitly specify `store(&VERSION) '14.0'`.
Also:
* synchronised error codes between .h and .pas.
* synchronised touch layout tags between Developer and KeymanWeb, and
cleaned up builder.js usage thereof.
* added support for KeymanwebOsk font override when special tags are
identified.
* added basic tests to ensure that the compiler is catching use of these
tags as needed.
* updated keymanweb-osk.ttf font in Developer.
Fixes#3562.
Second part of the two-part special with #3772. When Keyman
Configuration starts, it creates a task that is launched whenever a
specific Keyman event with id 256 is added to the Event Log. This task
launches keyman.exe to start Keyman (and if Keyman is already running,
the newly launched process will exit with no side effects).
This feature is behind a new feature flag `Flag_UseAutoStartTask`, so it
can be disabled in the event of compatibility issues.
The task is created or updated on each launch of Keyman Configuration
(or Keyman via the 'Keyman' shortcut in the Start Menu), and is
intended to be self-maintaining.
The test_starttask project (4 of the 12 files) is just a wrapper around
the start TKeymanStartTask class to allow for manual testing. No unit
tests for this at this time; I think it would be difficult to unit test
this effectively.
Fixes#3084.
This does two things:
1. Cleans up a bunch of places where we used to use `(int)` typecasts
for pointer math, which was problematic. We now use `(INT_PTR)` per
MSDN https://docs.microsoft.com/en-us/windows/win32/winprog64/rules-for-using-pointers
and then cast that down to `(int)` where necessary, e.g. when storing
string lengths which are never going to be more than a few hundred
characters! Doing this explicitly helps to clarify that we are aware
of the typecast and believe it to be safe.
2. Adds in some build infrastructure for future use of Coverity Scan
https://scan.coverity.com/ which we plan to use for further code
quality updates. I have submitted the project to Coverity and are
now waiting for approval so we can check results. Once we have
approval, I do plan to add this to the nightly build (we need to
keep submissions under 3 builds/day).
Note: I have not yet added Keyman Core (Windows) to this project,
nor are we currently building Keyman Core (macOS) or Keyman for
Linux, but we should consider adding those in future.
unit test for structure sizes. This validates that the Pascal and C++
structure definitions are identical in size for each platform that they
are compiled for (x86 and x64).
Note that this uncovered an existing discrepancy in FILE_KEYBOARD. ;-)
