Adds a new set of 'New Project' dialogs to allow authors to easily copy
keyboards from local filesystem, Keyman Cloud (including a keyboard
search web page, implemented in keymanapp/keyman.com#536), and
directly from a GitHub URL. Adds related documentation.
Fixes: #13073
Depends-on: keymanapp/keyman.com#536
Adds 'verbose' and 'debug' log levels and corresponding error severity
levels. This means the internal error severity values have changed to
match - 'info' is now 2 instead of 0.
Fixes: #12975
Fixes#9923.
These are no longer used because we now use kmc for builds. This also
means that the kmcomp-x64-structures test is no longer required, because
that was used to keep the Delphi and C++ structures in sync.
There are some minor details around error message identifiers that are
still present in a handful of places, but they are work for another
time.
Fixes#9889.
This arises from a deprecated way of using Keyman Developer by starting
Keyman Developer by opening a keyboard .kmn file from Explorer, which
causes Developer to run in a 'projectless' mode. This was not tested in
the new compiler integration, and that has caused this crash.
In 'projectless' mode, there is still a global 'untitled' project, but
the files loaded do not 'belong' to it. The compiler settings are
inherited from the global 'untitled' project in this case.
Fixes#9551.
Removes various .keyboard_info files from test fixtures and also removes
generation of .keyboard_info source files from kmconvert, alongside now-
redundant tests (cvt.dpr).
Removes kmcomp.dpr, related source, compilekeymanweb.pas, and related
unit tests.
Cleans up a couple of bits and pieces around kmc in order to help tests
to pass, and updates some tests that had legacy code in them
(particularly missing &TARGETS stores).
Removes the following fields:
* legacyId
* documentationFilename
* documentationFileSize
* links
* related[].note
None of these fields are needed any longer; see #9351 for steps to
remove data.
Eliminates difference between keyboard_info source and distribution,
renaming to keyboard_info.schema.json, and updating the required members
of the json accordingly.
Will have corresponding commits in keyman.com, api.keyman.com,
help.keyman.com, and keyboards repositories.
Fixes#7005.
If a developer used single digit values in stores, unquoted (which is
not really the usual approach, but should work just fine for non-zero
values), the KMW compiler would emit invalid single-digit hexadecimal
escapes for them, e.g. `"\x1"` instead of `"\x01"`.
Sample code:
```
store(option) 1
if(option = 1) + 'a' > 'one'
if(option = 2) + 'a' > 'two'
+ '1' > set(option = 1)
+ '2' > set(option = 2)
```
It is not immediately obvious from this code, but the value `1` is
actually a character with value `'\x01'` or `U+0001`!
The more usual approach will not encounter this problem:
```
store(option) '1'
if(option = '1') + 'a' > 'one'
if(option = '2') + 'a' > 'two'
+ '1' > set(option = '1')
+ '2' > set(option = '2')
```
Note that the following is a compile error (due to internal use of
null terminated strings).
```
store(option) 0
```
Fixes#7216.
The warning message 0x209A 'The rule will never be matched because its
key code is never fired.' was being generated multiple times for a
single line because the `JavaScript_Key` function it is generated by is
used for various purposes.
This PR keeps a cache of reported key rules to ensure that the message
is reported only once for a given key rule, and also improves the
reporting to clarify which specific key is unreachable, which makes it
easier to diagnose when using `any(k)` style messages, for example:
```
lao_phonetic.kmn (237): Warning: 209A The rule will never be matched for key 'ñ' because its key code is never fired.
```
This also reduces the warning to a hint, as this should not be a
blocking issue for a keyboard, rather just a place the keyboard author
can tidy up.
Picked up while reviewing code for conversion to C++. The compiler
could, in some circumstances emit garbage code for readonly groups
because we weren't testing all scenarios correctly. In practice, this
would have been rare as readonly groups don't emit characters, but it
should be fixed!
Fixes#6799.
For KeymanWeb compiled keyboards, readonly groups should never emit any
output. Rules in these groups permitted only to:
* `use` other readonly groups
* `call` external functions (which MUST NOT emit output)
* `set`, `reset` or `save` store values
The base kmx compiler does emit output for rules in readonly groups.
Thus, the KeymanWeb compiler, when it transpiles from the generated
.kmx, needs to omit output for any readonly group, while avoiding any
other potential change in behaviour.
