Add an efficient way to iterate over the assigned keysyms.
Currently only provided for testing, so we guard it by
`ENABLE_PRIVATE_APIS` in order to reduce the installed library.
Currently there is no direct way to know the minimum and maximum keysym
values that are assigned, i.e. that have an explicit name or are
Unicode keysyms.
Introduce the new following internal API:
- XKB_KEYSYM_MIN_ASSIGNED
- XKB_KEYSYM_MAX_ASSIGNED
- XKB_KEYSYM_MIN_EXPLICIT
- XKB_KEYSYM_MAX_EXPLICIT
- XKB_KEYSYM_COUNT_EXPLICIT
Also add a bunch of tests to ensure consistant keysyms bounds.
I couldn't find any reference to *how* the keymap format actually needs to look
like if you want multiple keysyms per level. So let's add a test for it and a
minimal documentation entry.
Add excerpt of `util-mem.h` from libei defining the macro `steal`, in
order to improve memory management and the code semantics.
See: 38132d6fc5/src/util-mem.h (L92)
Previously the attribute “popularity” was completely ignored. It also
did not respect the modified DTD, because its default value depends if
we are currently parsing an “extras” rules file.
Fixed:
- Always parse the popularity attribute.
- Change the DTD to reflect that the default value is implied.
Current options to set the locale are convoluted:
- An explicit locale *must* be given, while a sane default would be
to use the user environment.
- Then there are two options that were useful while testing locale
handling: read environment variables or use `setlocale`. But the
program has already called:
```
setlocale(LC_ALL, "");
```
so it turns out the two options lead to the same results.
Remove options `--locale-from-env` and `--locale-from-setlocale`
and make the locale default to the user environment.
- Add check for recursive includes of keymap components. It relies on
limiting the include depth. The threshold is currently to 15, which
seems reasonable with plenty of margin for keymaps in the wild.
- Add corresponding new log message `recursive-include`.
- Add tests for recursive includes.
The string `buf` was not freed after each call to `asprintf_safe`.
Avoid allocating and introduce the new message: `XKB_ERROR_INSUFFICIENT_BUFFER_SIZE`.
When there is no error the types are “stolen” and copied to the keymap.
But when there is an error, `MergeIncludedKeyTypes` just return without
“stealing” nor freeing the types.
Fixed by explicitly freeing the key types.
Fixed another leak in `HandleKeyTypeDef` that may occur if there is an
error in parsing a type definition.
GCC 14 introduces a new -Walloc-size included in -Wextra which gives:
```
src/state.c:589:9: warning: allocation of insufficient size ‘1’ for type ‘struct xkb_state’ with size ‘128’ [-Walloc-size]
```
The calloc prototype is:
```
void *calloc(size_t nmemb, size_t size);
```
So, just swap the number of members and size arguments to match the prototype, as
we're initialising 1 struct of size `sizeof(struct xkb_state)`. GCC then sees we're not
doing anything wrong.
Signed-off-by: Sam James <sam@gentoo.org>
Leading BOM is legal and is used as a signature — an indication that
an otherwise unmarked text file is in UTF-8.
See: https://www.unicode.org/faq/utf_bom.html#bom5 for further details.
Leading BOM is legal and is used as a signature — an indication that
an otherwise unmarked text file is in UTF-8.
See: https://www.unicode.org/faq/utf_bom.html#bom5 for further
details.
Leading BOM is legal and is used as a signature — an indication that
an otherwise unmarked text file is in UTF-8.
See: https://www.unicode.org/faq/utf_bom.html#bom5 for further details.
The handling of keysym name guards (e.g. `#ifndef XK_Ydiaeresis`) was
incomplete and led to a missing keysym.
Make `sripts/makeheader` more robust to C macros handling.
- Add bash completion script. It parses the commands help messages to
provide the completions, thus any new subcommand or option will be
supported, as long as it has its entry in the help messages. This
should result in low maintenancei effort.
- Add installation entry in Meson. The path can be configured using
the following options:
- `enable-bash-completion` to enable the installation;
- `bash-completion-path` to control the installation path. It will
default to: `share/bash-completion/completions`.
TODO: completion for other shells, such as zsh?
See https://pre-commit.com for further info. Current checks:
- Whitespaces
- Yaml
- Large files
- Python linting/formatting
TODO: investigate options for C linter and formatter
- Update keymap to use reference keysym names.
- Fix x11comp test by handling old x11proto.
We need xkbcomp to be compiled with at least x11proto-dev 2023.2.
So we replace the unsupported keysyms with supported ones not
already in the keymap. This is kind of ugly, but it works. If we
ever want to restore the original keysyms with their supported names,
the substitute keysyms will be easy to spot.
The octal parser accepts the range `\1..\777`. The result is cast to
`char` which will silently overflow.
This commit prevents overlow and will treat `\400..\777` as invalid
escape sequences.
NULL usually terminates the strings; allowing to produce it via escape
sequences may lead to undefined behaviour.
- Make NULL escape sequences (e.g. `\0` and `\x0`) invalid.
- Add corresponding test.
- Introduce the new message: XKB_WARNING_INVALID_ESCAPE_SEQUENCE.
Allow users to iterate the entries in a compose table. This is useful
for other projects which want programmable access to the sequences,
without having to write their own parser.
- New API:
- `xkb_compose_table_entry_sequence`;
- `xkb_compose_table_entry_keysym`;
- `xkb_compose_table_entry_utf8`;
- `xkb_compose_table_iterator_new`;
- `xkb_compose_table_iterator_free`;
- `xkb_compose_table_iterator_next`.
- Add tests in `test/compose.c`.
- Add benchmark for compose traversal.
- `tools/compose.c`:
- Print entries instead of just validating them.
- Add `--file` option.
- TODO: make this tool part of the xkbcli commands.
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
Co-authored-by: Ran Benita <ran@unusedvar.com>
Signed-off-by: Ran Benita <ran@unusedvar.com>
Previously we had two types of macros for logging: with and without
message code. They were intended to be merged afterwards.
The idea is to use a special code – `XKB_LOG_MESSAGE_NO_ID = 0` – that
should *not* be displayed. But we would like to avoid checking this
special code at run time. This is achieved using macro tricks; they
are detailed in the code (see: `PREPEND_MESSAGE_ID`).
Now it is also easier to spot the remaining undocumented log entries:
just search `XKB_LOG_MESSAGE_NO_ID`.
Pierre Le Marre
Peter Hutterer
Brendan Le Foll
ppw0
Sam James
Ran Benita