Fixes#9100.
The `compilerWarningsAsErrors` option can be passed in as a command-line
option or in the project options. Command-line option, if present, takes
precedence over the project option. If neither is set, then the value is
`false`.
Handling of this is within kmc, rather than individual modules.
Fixes#9233.
Adds --color and --no-color switches to kmc command line, with default
being determined by console mode.
Also ensures color initialization happens just once in
NodeCompilerCallbacks and moves constants to top of file.
Fixes#8795.
Relates to #9090.
Cleans up and makes consistent compiler messages in kmc, and related
unit tests.
Adds support for colorized messages.
After installing chalk for ansi coloring in kmc, @types/node needed to
be brought in sync with the Typescript version, per the suggestion of
checking against `npm dist-tags @types/node`,found in a discussion at
https://github.com/DefinitelyTyped/DefinitelyTyped/discussions/64262#discussioncomment-4905069
Additional tidying up includes:
* Deprecating a set of functions in compiler-interfaces, bringing them
together under a new CompilerError class.
Separating CompilerErrorSeverity and CompilerErrorMask enums.
* Making CompilerError.formatEvent (formerly compilerEventFormat) print
messages in the same format as NodeCompilerCallbacks (sans coloring).
* Adding a wrapper class for CompilerCallbacks that manages the filename
reporting, used currently exclusively by kmc itself.
Fixes#9208.
Fixes#9209.
Fixes#9203.
Fixes#9198.
The changes here overlap in kmp-compiler.ts. Addresses several issues
with the package compiler:
* refactors the reading of the metadata from keyboards to make use of it
when refreshing the keyboard metadata in kmp.json (#9208). This is the
bulk of the changes.
* Fixes case on some fields in the kps file format (#9209)
* Removes code which emitted strings table to kmp.json, as these were
only ever used for package installer executables (#9203)
* Cleans up code which emitted Start Menu items to make it match spec
(#9198)
Fixes#9184.
kmcomp was unable to track pure whitespace in .kvks files. To match this
behaviour, we should strip pure space whitespace from key element values
in .kvks files only.
Fixes#9178.
The values `pad`, `width`, and `hint` should not be emitted in a
compiled touch layout file, if they have default values of `0`, `0`,
or `""`, respectively. This matches the legacy kmcomp pattern.
Fixes#9177.
Some imported visual keyboards include `K_oDF` or `K_?C1` key codes.
These are not made visible in the UI but as they are "valid" VK codes,
they should not cause an error.
- update docs on UnicodeSet
- uset parser: fix/clarify that the wasm interface takes a bufferSize, but the ts interface takes a range count. This was muddled before.
For: #7377
Fixes#9154.
Improves performance in both kmcmplib and in kmc-kmn/kmw-compiler. After
these changes are applied, vietnamese_telex keyboard builds in around 6
seconds on my machine (down from over 2 minutes). This is certainly only
the surface of performance improvements we could make.
Addresses excessive memory reallocations in kmcmplib, by reallocating
store and key arrays in large chunks of 100 items rather than
reallocating on each new item added. This resulted in a 250x speed-up on
functions such as `AddStore` in WASM build.
Some careful modulus arithmetic was needed for resizing the key array,
which can be grown in larger increments.
Resolved excessive zeroing out of destination buffer in u16ncpy, which
was being called with an 8kb destination buffer on every line of the
file.
In the kmw side, vast majority of the performance cost was in copying of
buffers while loading a .kmx into memory, rather than creating views
into the memory. Essentially replaced this pattern:
```
return this.rString.fromBuffer(source.slice(offset));
```
with:
```
const data = new Uint8Array(source.buffer, source.byteOffset + offset);
return this.rString.fromBuffer(data);
```
Fixes#9160.
To match the behaviour of kmcomp, kmc should add/delete the following
fields when writing out a kmw touch layout:
* `platform.displayUnderlying` flag is always emitted by kmcomp, so kmc
should always emit it too.
* `platform.font` and `platform.fontsize` should be eliminated if empty
string
* `key.id` should be eliminated if empty string
Fixes#9140.
Fixes#9148.
Keyman Developer 9.0 .kpj files included a lot of additional state
metadata. We need a schema which validates these files, as they are
otherwise valid to load (we'll never save them any more). Rather than
add all the extra metadata to what is otherwise a fairly clean schema,
we'll provide a legacy .schema.json.
In the future, we may be able to merge these schemas, as we move towards
the .kpj 2.0 format which doesn't list files. Ideally, all three formats
(Keyman Developer 9.0 schema, call it legacy, 1.0 schema for Keyman
Developer 10.0+ which has Options and Files listed, 2.0 schema for
capturing just project settings for a folder) will be supported by a
single schema file.
- update element string constructors to support UnicodeString and the segmented array from ElementParser
- update compiler machinery to pass USetParser in the DependencySections
- test cases
#7377
- detect and reject nested square brackets, for now
- implement segmentation of reorder element strings,
including type identification (escape, codepoint, uset)
- tests
For #7377
When we read .kmx files, they have no alignment guarantees, so we need
to tell the compiler to generate unaligned-safe code for accesses to
`COMP_` structure members, because typically we point into the buffer
and read at any offset.
A .kmx file will generally be 2-byte aligned, as there are no structures
or data types with smaller than 2 byte widths. There is no requirement
that this be the case per the .kmx spec, though. So we use a 1 byte
alignment attribute for the compiler, so it will generate safe code when
reading these structs.
Note that we are assuming that `COMP_KEYBOARD` is aligned because it is
always the start of the file, so will be at the start of any buffer
which will automatically be aligned correctly.
We should probably review some of our design decisions and structs for
KMXPlus given this.
While .kvk includes a font color field, it is essentially unused. There
was also some sort of support provided for font style in the KeymanWeb
keyboard compiler, but this was never streamed into .kvk or .kvks files,
so was always a no-op.
Thus, this PR removes any semblance of support for font style and color
from the .kvk and .kvks readers and writers. When we write the font
color field which is present in .kvk, we always use the default
TColor.clWindowText which is what the legacy Delphi-based writer would
always have written.
Also sorted out the default font size and name in the .kvk transform
from .kvks, and in so doing cleaned up the basic.kvk and basic.js in
LDML keyboard compiler to match what we are doing in the .kmn compiler.
