Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
# Error index {#error-index}
|
|
|
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
|
NOTE: This file has been generated automatically by “update-message-registry.py”.
|
|
|
|
|
|
Do not edit manually!
|
|
|
|
|
|
-->
|
|
|
|
|
|
|
|
|
|
|
|
This page lists the warnings and errors generated by xkbcommon.
|
2023-09-21 12:06:27 -06:00
|
|
|
|
There are currently 52 entries.
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
|
|
|
|
|
|
@todo The documentation of the log messages is a work in progress.
|
|
|
|
|
|
|
|
|
|
|
|
## Index
|
|
|
|
|
|
|
|
|
|
|
|
| Code | Identifier | Description | Type |
|
|
|
|
|
|
| --------- | ---------------------------- | ----------- | ---- |
|
|
|
|
|
|
| [XKB-034] | `malformed-number-literal` | Warn on malformed number literals | Error |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-043] | `conflicting-key-type-preserve-entries` | Conflicting “preserve” entries in a key type | Warning |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-060] | `unsupported-modifier-mask` | Warn on unsupported modifier mask | Error |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-077] | `expected-array-entry` | Expected an array entry, but the index is missing | Error |
|
|
|
|
|
|
| [XKB-101] | `illegal-keycode-alias` | Illegal keycode alias with the name of a real key | Warning |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-107] | `unrecognized-keysym` | Warn on unrecognized keysyms | Warning |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-123] | `undeclared-virtual-modifier` | A virtual modifier is used before being declared | Error |
|
|
|
|
|
|
| [XKB-150] | `wrong-statement-type` | The type of the statement is not allowed in the context | Error |
|
|
|
|
|
|
| [XKB-172] | `unsupported-geometry-section` | Geometry sections are not supported | Warning |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-183] | `cannot-infer-key-type` | Warn if no key type can be inferred | Warning |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-195] | `illegal-key-type-preserve-result` | The result of a key type “preserve” entry must be a subset of its input modifiers. | Warning |
|
|
|
|
|
|
| [XKB-203] | `invalid-include-statement` | Syntax error in the include statement | Error |
|
|
|
|
|
|
| [XKB-206] | `invalid-modmap-entry` | A modmap entry is invalid | Error |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-237] | `unsupported-group-index` | Warn when a group index is not supported | Error |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-239] | `conflicting-key-type-level-names` | The name of a key type level is defined multiple times. | Warning |
|
|
|
|
|
|
| [XKB-254] | `invalid-set-default-statement` | Invalid statement setting default values | Error |
|
|
|
|
|
|
| [XKB-266] | `conflicting-key-type-map-entry` | Conflicting “map” entries in type definition | Warning |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-286] | `undefined-key-type` | Warn if using an undefined key type | Warning |
|
|
|
|
|
|
| [XKB-305] | `non-base-group-name` | Warn if a group name was defined for group other than the first one | Warning |
|
|
|
|
|
|
| [XKB-312] | `unsupported-shift-level` | Warn when a shift level is not supported | Error |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-338] | `included-file-not-found` | Could not find a file used in an include statement | Error |
|
|
|
|
|
|
| [XKB-345] | `unknown-operator` | Use of an operator that is unknown and thus unsupported | Error |
|
|
|
|
|
|
| [XKB-378] | `duplicate-entry` | An entry is duplicated and will be ignored | Warning |
|
|
|
|
|
|
| [XKB-407] | `conflicting-key-type-definitions` | Conflicting definitions of a key type | Warning |
|
|
|
|
|
|
| [XKB-428] | `wrong-scope` | A statement is in a wrong scope and should be moved | Error |
|
|
|
|
|
|
| [XKB-433] | `missing-default-section` | Missing default section in included file | Warning |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-461] | `conflicting-key-symbol` | Warn if there are conflicting keysyms while merging keys | Warning |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-478] | `invalid-operation` | The operation is invalid in the context | Error |
|
2023-09-18 10:17:39 -06:00
|
|
|
|
| [XKB-489] | `numeric-keysym` | Warn on numeric keysym (other than 0-9) | Warning |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-516] | `extra-symbols-ignored` | <span class="todo">TODO:</span> add description | Warning |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-523] | `conflicting-key-name` | Conflicting definitions of a key name or alias | Warning |
|
|
|
|
|
|
| [XKB-550] | `allocation-error` | Cannot allocate memory | Error |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-578] | `wrong-field-type` | Warn when a field has not the expected type | Error |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-623] | `invalid-real-modifier` | Invalid _real_ modifier | Error |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-645] | `unknown-char-escape-sequence` | Warn on unknown escape sequence in string literal | Warning |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-661] | `invalid-included-file` | The target file of an include statement could not be processed | Error |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-700] | `multiple-groups-at-once` | Warn if a key defines multiple groups at once | Warning |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-711] | `unsupported-symbols-field` | A legacy X11 symbol field is not supported | Warning |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-769] | `invalid-syntax` | The syntax is invalid and the file cannot be parsed | Error |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-770] | `undefined-keycode` | Reference to an undefined keycode | Warning |
|
|
|
|
|
|
| [XKB-784] | `invalid-expression-type` | An expression has not the expected type | Error |
|
|
|
|
|
|
| [XKB-796] | `invalid-value` | A value is invalid and will be ignored | Error |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-800] | `conflicting-modmap` | Warn if there are conflicting modmap definitions | Warning |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-812] | `unknown-field` | A field is unknown and will be ignored | Error |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-883] | `conflicting-key-action` | Warn if there are conflicting actions while merging keys | Warning |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-893] | `conflicting-key-type-merging-groups` | Warn if there are conflicting key types while merging groups | Warning |
|
|
|
|
|
|
| [XKB-901] | `conflicting-key-symbols-entry` | Conflicting symbols entry for a key | Error |
|
|
|
|
|
|
| [XKB-903] | `missing-symbols-group-name-index` | Missing group index in a group name entry | Warning |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-935] | `conflicting-key-fields` | Warn if there are conflicting fields while merging keys | Warning |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-949] | `invalid-identifier` | An identifier is used but is not built-in | Error |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
| [XKB-965] | `unresolved-keymap-symbol` | Warn if using a symbol not defined in the keymap | Warning |
|
2023-09-21 12:06:27 -06:00
|
|
|
|
| [XKB-971] | `undeclared-modifiers-in-key-type` | Some modifiers used in a key type “map” or “preserve” entry are not declared | Warning |
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
|
|
|
|
|
|
## Details
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-034 – Malformed number literal {#XKB-034}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn on malformed number literals</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
xkbcommon can parse the following number literal formats:
|
|
|
|
|
|
|
|
|
|
|
|
- *decimal integer:* 1, 123, etc.
|
|
|
|
|
|
- *decimal floating-point number:* 1.23, etc.
|
|
|
|
|
|
- *hexadecimal integer:* prefixed with “0x”: 0x123, 0xff, 0xAB, etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-043 – Conflicting key type preserve entries {#XKB-043}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Conflicting “preserve” entries in a key type</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-060 – Unsupported modifier mask {#XKB-060}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn on unsupported modifier mask</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-077 – Expected array entry {#XKB-077}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Expected an array entry, but the index is missing</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-101 – Illegal keycode alias {#XKB-101}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Illegal keycode alias with the name of a real key</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-107 – Unrecognized keysym {#XKB-107}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn on unrecognized keysyms</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
xkbcommon replaces keysyms it does not recognize by the keysym `NoSymbol`.
|
|
|
|
|
|
|
|
|
|
|
|
You may find the list of supported keysyms in
|
|
|
|
|
|
`include/xkbcommon/xkbcommon-keysyms.h`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### Examples
|
|
|
|
|
|
|
|
|
|
|
|
<details>
|
|
|
|
|
|
<summary>Unrecognized keysym “`coma`”</summary>
|
|
|
|
|
|
|
|
|
|
|
|
**Error message:**
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
xkbcommon: WARNING: [XKB-107] de:31:20: unrecognized keysym "coma"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
xkbcommon does not recognize the keysym “`coma`”. It is most probably
|
|
|
|
|
|
a typo for “<code>com<em>m</em>a</code>”.
|
|
|
|
|
|
See: `XKB_KEY_comma` in `include/xkbcommon/xkbcommon-keysyms.h`.
|
|
|
|
|
|
|
|
|
|
|
|
**Fix:**
|
|
|
|
|
|
<div class="example-container">
|
|
|
|
|
|
<div class="example">
|
|
|
|
|
|
<div class="example-inner">
|
|
|
|
|
|
<div class="example-title">Before</div>
|
|
|
|
|
|
```c
|
|
|
|
|
|
key <AB08> {[ coma, semicolon, periodcentered, multiply ]};
|
|
|
|
|
|
```
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="example">
|
|
|
|
|
|
<div class="example-inner">
|
|
|
|
|
|
<div class="example-title">After</div>
|
|
|
|
|
|
```c
|
|
|
|
|
|
key <AB08> {[ comma, semicolon, periodcentered, multiply ]};
|
|
|
|
|
|
```
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</details>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-123 – Undeclared virtual modifier {#XKB-123}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>A virtual modifier is used before being declared</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-150 – Wrong statement type {#XKB-150}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>The type of the statement is not allowed in the context</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-172 – Unsupported geometry section {#XKB-172}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Geometry sections are not supported</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-183 – Cannot infer key type {#XKB-183}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn if no key type can be inferred</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-195 – Illegal key type preserve result {#XKB-195}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>The result of a key type “preserve” entry must be a subset of its input modifiers.</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-203 – Invalid include statement {#XKB-203}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Syntax error in the include statement</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-206 – Invalid modmap entry {#XKB-206}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>A modmap entry is invalid</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-237 – Unsupported group index {#XKB-237}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn when a group index is not supported</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
xkbcommon supports group index in the range (1..4).
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-239 – Conflicting key type level names {#XKB-239}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>The name of a key type level is defined multiple times.</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-254 – Invalid set default statement {#XKB-254}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Invalid statement setting default values</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-266 – Conflicting key type map entry {#XKB-266}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Conflicting “map” entries in type definition</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-286 – Undefined key type {#XKB-286}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn if using an undefined key type</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-305 – Non base group name {#XKB-305}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn if a group name was defined for group other than the first one</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-312 – Unsupported shift level {#XKB-312}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn when a shift level is not supported</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
Shift levels are _one_-indexed. xkbcommon supports two formats of shift levels:
|
|
|
|
|
|
as numbers and as identifiers `LevelN`, where `N` is in the range (1..8).
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-338 – Included file not found {#XKB-338}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Could not find a file used in an include statement</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-345 – Unknown operator {#XKB-345}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Use of an operator that is unknown and thus unsupported</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-378 – Duplicate entry {#XKB-378}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>An entry is duplicated and will be ignored</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-407 – Conflicting key type definitions {#XKB-407}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Conflicting definitions of a key type</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
The given key type is defined multiple times, but only one definition is kept.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-428 – Wrong scope {#XKB-428}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>A statement is in a wrong scope and should be moved</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-433 – Missing default section {#XKB-433}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Missing default section in included file</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
When using an include statement, the included file may contains multiple sections.
|
|
|
|
|
|
The include statement may specify the name of the section to include, or leave it
|
|
|
|
|
|
unspecified. In the latter case, the included file must then define a *default* section.
|
|
|
|
|
|
The present warning is shown when no default section is defined.
|
|
|
|
|
|
|
|
|
|
|
|
To solve this, either fix the include statement by specifying the exact section to
|
|
|
|
|
|
include, or declare a default section in the included file.
|
|
|
|
|
|
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-461 – Conflicting key symbol {#XKB-461}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn if there are conflicting keysyms while merging keys</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-478 – Invalid operation {#XKB-478}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>The operation is invalid in the context</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-18 10:17:39 -06:00
|
|
|
|
### XKB-489 – Numeric keysym {#XKB-489}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.6.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn on numeric keysym (other than 0-9)</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
Numeric keysyms are not human-friendly. Use the corresponding named keysym
|
|
|
|
|
|
or Unicode keysym, if available.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### Examples
|
|
|
|
|
|
|
|
|
|
|
|
<details>
|
|
|
|
|
|
<summary>Hexadecimal keysym `0x1001ed0`</summary>
|
|
|
|
|
|
|
|
|
|
|
|
**Error message:**
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
xkbcommon: WARNING: [XKB-489] numeric keysym "0x1001ed0"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
**Fix:**
|
|
|
|
|
|
<div class="example-container">
|
|
|
|
|
|
<div class="example">
|
|
|
|
|
|
<div class="example-inner">
|
|
|
|
|
|
<div class="example-title">Before</div>
|
|
|
|
|
|
```c
|
|
|
|
|
|
key <AE01> { [ 0x1001ed0] };
|
|
|
|
|
|
```
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="example">
|
|
|
|
|
|
<div class="example-inner">
|
|
|
|
|
|
<div class="example-title">After</div>
|
|
|
|
|
|
```c
|
|
|
|
|
|
// Preferred form: human-friendly
|
|
|
|
|
|
key <AE01> { [ Ocircumflexacute ] };
|
|
|
|
|
|
// or
|
|
|
|
|
|
key <AE01> { [ U1ED0 ] };
|
|
|
|
|
|
```
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
</details>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-516 – Extra symbols ignored {#XKB-516}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd><span class="todo">TODO:</span> add description</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-523 – Conflicting key name {#XKB-523}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Conflicting definitions of a key name or alias</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-550 – Allocation error {#XKB-550}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Cannot allocate memory</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-578 – Wrong field type {#XKB-578}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn when a field has not the expected type</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-623 – Invalid real modifier {#XKB-623}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Invalid _real_ modifier</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-645 – Unknown char escape sequence {#XKB-645}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn on unknown escape sequence in string literal</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
xkbcommon support the following escape sequences in string literals:
|
|
|
|
|
|
|
|
|
|
|
|
| Escape sequence | Corresponding character |
|
|
|
|
|
|
| --------------- | ----------------------------------- |
|
|
|
|
|
|
| `\b` | `U+0008` Backspace |
|
|
|
|
|
|
| `\t` | `U+0009` Character tabulation |
|
|
|
|
|
|
| `\n` | `U+000A` Line feed |
|
|
|
|
|
|
| `\v` | `U+000B` Vertical tabulation |
|
|
|
|
|
|
| `\f` | `U+000C` Form feed |
|
|
|
|
|
|
| `\r` | `U+000D` Carriage return |
|
|
|
|
|
|
| `\e` | `U+001B` Escape |
|
|
|
|
|
|
| `\\` | `U+005C` Backslash |
|
|
|
|
|
|
| `\NNN` | _Octal_ escape, from `\0` to `\777` |
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-661 – Invalid included file {#XKB-661}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>The target file of an include statement could not be processed</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-700 – Multiple groups at once {#XKB-700}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn if a key defines multiple groups at once</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-711 – Unsupported symbols field {#XKB-711}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>A legacy X11 symbol field is not supported</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-769 – Invalid syntax {#XKB-769}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>The syntax is invalid and the file cannot be parsed</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-770 – Undefined keycode {#XKB-770}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
2023-09-21 12:06:27 -06:00
|
|
|
|
<dt>Summary</dt><dd>Reference to an undefined keycode</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-784 – Invalid expression type {#XKB-784}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>An expression has not the expected type</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-796 – Invalid value {#XKB-796}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>A value is invalid and will be ignored</dd>
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-800 – Conflicting modmap {#XKB-800}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn if there are conflicting modmap definitions</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
@todo detailed explanation and examples
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-812 – Unknown field {#XKB-812}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>A field is unknown and will be ignored</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-883 – Conflicting key action {#XKB-883}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn if there are conflicting actions while merging keys</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-893 – Conflicting key type merging groups {#XKB-893}
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn if there are conflicting key types while merging groups</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-901 – Conflicting key symbols entry {#XKB-901}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Conflicting symbols entry for a key</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
### XKB-903 – Missing symbols group name index {#XKB-903}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Missing group index in a group name entry</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-935 – Conflicting key fields {#XKB-935}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn if there are conflicting fields while merging keys</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-949 – Invalid identifier {#XKB-949}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Error</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>An identifier is used but is not built-in</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
### XKB-965 – Unresolved keymap symbol {#XKB-965}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Warn if using a symbol not defined in the keymap</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
2023-09-21 12:06:27 -06:00
|
|
|
|
### XKB-971 – Undeclared modifiers in key type {#XKB-971}
|
|
|
|
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
<dt>Since</dt><dd>1.0.0</dd>
|
|
|
|
|
|
<dt>Type</dt><dd>Warning</dd>
|
|
|
|
|
|
<dt>Summary</dt><dd>Some modifiers used in a key type “map” or “preserve” entry are not declared</dd>
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
|
|
|
|
The modifiers used in `map` or `preserve` entries should be declared using the entry
|
|
|
|
|
|
`modifiers` in the key type.
|
|
|
|
|
|
|
|
|
|
|
|
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-034]: @ref XKB-034
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-043]: @ref XKB-043
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-060]: @ref XKB-060
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-077]: @ref XKB-077
|
|
|
|
|
|
[XKB-101]: @ref XKB-101
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-107]: @ref XKB-107
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-123]: @ref XKB-123
|
|
|
|
|
|
[XKB-150]: @ref XKB-150
|
|
|
|
|
|
[XKB-172]: @ref XKB-172
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-183]: @ref XKB-183
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-195]: @ref XKB-195
|
|
|
|
|
|
[XKB-203]: @ref XKB-203
|
|
|
|
|
|
[XKB-206]: @ref XKB-206
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-237]: @ref XKB-237
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-239]: @ref XKB-239
|
|
|
|
|
|
[XKB-254]: @ref XKB-254
|
|
|
|
|
|
[XKB-266]: @ref XKB-266
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-286]: @ref XKB-286
|
|
|
|
|
|
[XKB-305]: @ref XKB-305
|
|
|
|
|
|
[XKB-312]: @ref XKB-312
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-338]: @ref XKB-338
|
|
|
|
|
|
[XKB-345]: @ref XKB-345
|
|
|
|
|
|
[XKB-378]: @ref XKB-378
|
|
|
|
|
|
[XKB-407]: @ref XKB-407
|
|
|
|
|
|
[XKB-428]: @ref XKB-428
|
|
|
|
|
|
[XKB-433]: @ref XKB-433
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-461]: @ref XKB-461
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-478]: @ref XKB-478
|
2023-09-18 10:17:39 -06:00
|
|
|
|
[XKB-489]: @ref XKB-489
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-516]: @ref XKB-516
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-523]: @ref XKB-523
|
|
|
|
|
|
[XKB-550]: @ref XKB-550
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-578]: @ref XKB-578
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-623]: @ref XKB-623
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-645]: @ref XKB-645
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-661]: @ref XKB-661
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-700]: @ref XKB-700
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-711]: @ref XKB-711
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-769]: @ref XKB-769
|
|
|
|
|
|
[XKB-770]: @ref XKB-770
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-784]: @ref XKB-784
|
|
|
|
|
|
[XKB-796]: @ref XKB-796
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-800]: @ref XKB-800
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-812]: @ref XKB-812
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-883]: @ref XKB-883
|
|
|
|
|
|
[XKB-893]: @ref XKB-893
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-901]: @ref XKB-901
|
|
|
|
|
|
[XKB-903]: @ref XKB-903
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-935]: @ref XKB-935
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-949]: @ref XKB-949
|
Structured log messages with a message registry
Currently there is little structure in the log messages, making
difficult to use them for the following use cases:
- A user looking for help about a log message: the user probably
uses a search engine, thus the results will depend on the proper
indexing of our documentation and the various forums. It relies
only on the wording of the message, which may change with time.
- A user wants to filter the logs resulting of the use of one of the
components of xkbcommon. A typical example would be testing
xkeyboard-config against libxkbcommon. It requires the use of a
pattern (simple words detection or regex). The issue is that the
pattern may become silently out-of-sync with xkbcommon.
A common practice (e.g. in compilers) is to assign unique error codes
to reference theses messages, along with an error index for
documentation.
Thus this commit implements the following features:
- Create a message registry (message-registry.yaml) that defines the
log messages produced by xkbcommon. This is a simple YAML file that
provides, for each message:
- A unique numeric code as a short identifier. It is used in the
output message and thus can be easily be filtered to spot errors
or searched in the internet. It must not change: if the
semantics of message changes, it is better to introduce a new
message for clarity.
- A unique text identifier, meant for two uses:
1. Generate constants dealing with log information in our code
base.
2. Generate human-friendly names for the documentation.
- A type: currently warning or error. Used to prefix the constants
(see hereinabove) and for basic classification in documentation.
- A short description, used as concise and mandatory documentation.
- An optionnal detailed description.
- Optional examples, intended to help the user to fix issues
themself.
- Version of xkbcommon it was added. For old entries this often
unknown, so they will default to 1.0.0.
- Version of xkbcommon it was removed (optional)
No entry should ever be deleted from this index, even if the message
is not used anymore: it ensures we have unique identifiers along the
history of xkbcommon, and that users can refer to the documentation
even for older versions.
- Add the script update-message-registry.py to generate the following
files:
- messages.h: message code enumeration for the messages currently
used in the code base. Currently a private API.
- message.registry.md: the error index documentation page.
- Modify the logging functions to use structured messages. This is a
work in progress.
2023-09-18 10:17:34 -06:00
|
|
|
|
[XKB-965]: @ref XKB-965
|
2023-09-21 12:06:27 -06:00
|
|
|
|
[XKB-971]: @ref XKB-971
|