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.
2.7 KiB
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.
-
tidyMessageCodes- starts with the valuetidyMessageCodes_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. -
tidyMessagesMisc- starts with the valuetidyMessagesMisc_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;