Fixes#5440.
Currently, the behavior of `use()` and `match` for KeymanWeb compiled
keyboards is not identical to the Windows (or Core) behavior. The
example keyboard in #5440 generates 'foo' instead of 'abc' on web.
This fixes that by ensuring that `match` is not called when `use()` is
found in a group rule match.
This does not trigger a build failure; validation warnings currently always pass.
Info messages are currently suppressed with -s which also suppresses the banner,
which is more plumbing than we should change just now.
Ensures we get a canonical tag per langtags.json as far as we possibly
can. This is a breaking change for the compiler as tags which were
formerly regarded as canonical are no longer regarded that way. This
mostly relates to script subtag but a secondary bug meant that some
other tags would have lost data in the canonicalization process
(because we did a lookup based only on the language subtag previously,
which is a no-no).
See keymanapp/keyboards#1452 for related work.
Fixes#4250.
This implements @jahorton's suggestion of including the original name
in a comment alongside the munged name, as well as appending the unique
integer identifier of each symbol.
Note: the error reporting code needed a massage to support Unicode error
strings; in the future we should update the C++ compiler to emit
Unicode error strings also.
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.
This is part 1 of 2 of a fix for #917. This adds in version 14.0
targeting and a new function `KNO` which is used in one specific place:
when a context() statement references a notany() statement. This
minimizes any risk in this change because existing supported patterns
should compile identically.
If the compiler finds this pattern, it will enforce 14.0 minimum version
for web targets.
Works around #119 on the compiler side. This normalises the touch layout file in the
compile phase, fixing integers which should be strings, etc. This means that
we no longer need to correct the issue in the Engine; a rebuild of affected
keyboards is sufficient (although of course we'll need a version bump in order
for them to be distributed.
ISO9995 describes keys by positions, where E00 is 5th (top) row,
left-most key. This feature allows keyboard developers to use
clearly positional identifiers in place of K_ identifiers.
Fixes#2498.
The .keyboard_info merge was incorrectly assuming the presence of a .js
in the .kmp file if the source .kmn file asserted support for touch
platforms, when testing the .kmx files. Now, platform support for
Android and iOS will only be added if the package actually includes the
.js file that makes that possible.
The .keyboard_info merge of `platformSupport` would not always give the
right result, for .js keyboards. We have a certain lack of information
in the .js which makes it a little tricky to determine precisely what
the set of supported platforms are. Thus, if we find a .js within a
.kmp, we'll assume it supports mobile; if we find a .js by itself,
we'll assume it supports web. (Thus, a keyboard that builds a .js
is assumed to always support web -- but not necessarily mobile now).
Some keyboards that have incorrectly added a .js into a package, e.g.
sil_cipher_music, will be marked as supporting mobile even though they
don't. The correct fix here is to remove the .js from the package for
that keyboard.
