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.
We have a `g_debug_ToConsole` variable. However, so far this was
always set to true and output to `syslog`. This change modifies
the default to `false`, and in that case logs to `syslog`. If
`g_debug_ToConsole` is true we no output to the console.
When running the KMX unit tests we set `g_debug_ToConsole` to true.
Fixes#3011.
Keys that have only whitespace will no longer generate separate key data
for the on screen keyboard, as they have no visual presentation anyway.
Fixes#2998.
Three parts to this:
* The package compiler will now give a warning if a keyboard in a
package does not contain any language metadata.
* Removed old canonicalization check during compile which is now handled
better in `TPackageInfoRefreshKeyboards`.
* Reduced non-canonical BCP 47 tag warnings in
`TPackageInfoRefreshKeyboards` to "info" so they do not block the
build.
Point 3 above is one part of the outcome of our BCP 47 discussion at:
https://docs.google.com/document/d/1N5CkTX7tlLlmUB9Mbd-LblY1ch1e642XxlTasC_WE_Q/edit#heading=h.fiy983iliay5
Fixes#3337.
In some situations, the wordlist editor was not tracking modified state
100% correctly, which meant that edits could be lost. This resolves that
by simplifying the modification state tracking.
Fixes#2556.
This adds support for `isRTL`, `insertAfterWord`, and
`quotesForKeepSuggestions` punctuation options for lexical models, both
in the parsing and in the user interface. A number of options are
presented to the user for the quotes and word breaking characters.
The parser continues to be a regex-based typescriptish parser. Expect it
to be gross. It's too big a job to do properly right now, so it is
somewhat limited and will bail if it finds structures it can't
understand.
I would hope to use something a bit smarter in the future to interface
with the editor. Probably when we are actually fully web-based and can
depend on a Typescript compiler directly.
Please don't get mad at me! 😟😟😟
Fixes#2740.
The definitions for several of the combined modifiers was incorrect,
which led to a mismatch when attempting to import those layers from a
visual keyboard into the touch layout editor.
Fixes#3199.
Ensures that the model package compiler passes schema validation for
kmp.json. Three problems were corrected:
1. `followKeyboardVersion` is a source-only property; it should not be
in deployable kmp.json.
2. `copyLocation` should have been a number not a string (in XML
everything is a string... but JSON has more control here)
3. `fileType` is a source-only property; it also should not be in
deployable kmp.json.
I have checked that the resulting files validate against the package
kmp.json schema version 1.1.0 defined at
https://github.com/keymanapp/api.keyman.com/blob/master/schemas/package/1.1.0/package.json.
None of these fixes should impact the use of these packages in target
apps. `followKeyboardVersion` and `fileType` are used only in the source
at package development time, and `copyLocation` is unused (and should be
eliminated from Keyman altogether in the future).
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.
