165acc4f3e
- Consolidated all output string definitions enums into `tidyenum.h`, which
is where they belong, and where they have proper visibility.
- Re-arranged `messages.c/h` with several comments useful to developers.
- Properly added the key lookup functions and the language localization
functions into tidy.h/tidylib.c with proper name-spacing.
- Previous point restored a *lot* of sanity to the #include pollution that's
been introduced in light of these.
- Note that opaque types have been (properly) introduced. Look at the updated
headers for `language.h`. In particular only an opaque structure is passed
outside of LibTidy, and so use TidyLangWindowsName and TidyLangPosixName
to poll these objects.
- Console application updated as a result of this.
- Removed dead code:
- void TY_(UnknownOption)( TidyDocImpl* doc, char c );
- void TY_(UnknownFile)( TidyDocImpl* doc, ctmbstr program, ctmbstr file );
- Redundant strings were removed with the removal of this dead code.
- Several enums were given fixed starting values. YOUR PROGRAMS SHOULD NEVER
depend on enum values. `TidyReportLevel` is an example of such.
- Some enums were removed as a result of this. `TidyReportLevel` now has
matching strings, so the redundant `TidyReportLevelStrings` was removed.
- All of the PO's and language header files were regenerated as a result of
the string cleanup and header cleanup.
- Made the interface to the library version and release date consistent.
- CMakeLists.txt now supports SUPPORT_CONSOLE_APP. The intention is to
be able to remove console-only code from LibTidy (for LibTidy users).
- Updated README/MESSAGES.md, which is *vastly* more simple now.
30 lines
2.7 KiB
Markdown
30 lines
2.7 KiB
Markdown
# Message System
|
|
|
|
Tidy has quite complex warning/error messaging system. This is all about adding a **new** warning or error message to **libTidy**.
|
|
|
|
First assign the message a key value. This is done in `tidyenum.h`, in one of the two enumerations that are listed there.
|
|
|
|
1. `tidyMessageCodes` - starts with the value `tidyMessageCodes_first = 500`, and it must be first. These are messages that appear in Tidy's report list, the list that's emitted telling you what Tidy did to your code. **However** don't modify this enum directly. You'll modify a preprocessor macro instead.
|
|
|
|
2. `tidyMessagesMisc` - starts with the value `tidyMessagesMisc_first = tidyMessageCodes_last`. These are messages that are emitted that tell you general information, such as further advice.
|
|
|
|
All enum values are only ever used by name within **libTidy** (and incidentally, should only ever be used by name in your client applications; never trust the value!), so feel free to enter new strings wherever they make the most sense. There are already existing categories (marked by comments), or feel free to create a new category if that's best.
|
|
|
|
As mentioned above, `tidyMessageCodes` messaged must be defined in one of the existing macros named like `FOREACH_...(FN)`, such as `FOREACH_MSG_ENTITIES(FN)`. These macros ensure that another data structure used for localization and key lookup is updated automatically any time strings are added or removed, thus limiting the possibility of developer error.
|
|
|
|
|
|
## Step 1
|
|
|
|
So in this case I want to add 3 warning messages: `BAD_SURROGATE_PAIR`, `BAD_SURROGATE_TAIL`, and `BAD_SURROGATE_LEAD`. Because these are error messages, they belong in the `tidyErrorCodes` enum, and they fit into nicely into the macro beginning `FOREACH_MSG_ENCODING(FN)`.
|
|
|
|
|
|
## Step 2
|
|
|
|
The next step is adding a `format` string to `language_en.h`. This string may later be translated to various supported language strings, but at present it is important that the other language translated strings, like `language_fr.h`, `language_es.h`, etc, keep the same format order.
|
|
|
|
Where to add this seems a bit of a mess, but in general things are grouped by where they're used in `libTidy`, and often in alphabetical order within those groups. Here I've added them relative to where they were placed in the other enums and structs.
|
|
|
|
Depending on which of the output routines you use (consult `message.c`) you may be able to use parameters such as `%u` and `%s` in your format strings. The available data is currently limited to the available message output routines, but perhaps generalizing this in order to make more data available will be a nice focus of Tidy 5.5. Please don't use `printf` for message output within **libTidy**.
|
|
|
|
eof;
|