output, classify and organize all of the dialogue type of messages. This paves
the way towards formalizing (and expanding!) the footnotes system with much
greater explanatory text, as well as providing much better fine-grained control
over which types of output that Tidy will produce.
Moved STRING_DOCTYPE_GIVEN, STRING_CONTENT_LOOKS, and STRING_NO_SYSID to the
Report paradigm from the Dialogue paradigm, as these are items that are
traditionally TidyInfo and included in the Report table, rather than any type
of dialogue.
At this point, we are exactly passing all tests.
the basic reporting functions that share the same signature. This also resulted
in eliminating a string, and adding a new string to disambiguate between
errors and warnings.
the remainder of the callbacks. TidyConfigCallback is now given a reference
to the instance of the TidyDoc that caused the callback to occur.
+ TidyConfigCallback
This PR refactors how picklists and option parsers are implemented in LibTidy,
making is vastly easier to implement new picklists in the future, as well as
modify some of the existing picklists such that they have more logical names.
Picklist arrays are now arrays of structures that include the possible strings
capable of setting a particular option value, and a new parser has been written
to work with these structures.
In addition, several of the existing parsers were removed, as they are now
redundant, and a couple of the remaining parsers were refactored to take
advantage of the new parser.
In effect, this means that:
- New parsers don't have to be written in the majority of cases where new
options are added that exceed yes/no/auto.
- Some of the existing options can have more meaningful names than yes/no/auto,
in a backward compatible way. For example, vertical-spacing "auto" currently
in no way reflects "auto" when used.
- Many, many updates to the public header files.
- tidyenum.h was reorganized substantially in order to better generate
documentation with Doxygen.
- This was also a good time to clean up all of the various enums for languages
and strings. Everything is simple and in a single enum now, other than a
couple of cases (TidyOptionId, for example, doesn't need to be redefined).
- A full and complete audit of the strings meant some opportunities to delete
useless strings.
- Reorganized the order of the strings in language_en.h in order to better
find things when programmers want to make changes. There are a lot fewer
internal "sections" now, and everything has been painstakingly sorted within
the remaining sections.
- Consequently rebased all of the PO's, POT, and other language files.
- Updated several of the READMEs with the newest information.
- Made the READMEs easier to copy into the Doxygen project by changing some of
the code format for compatibility, mainly the use of tildes instead of
backslashes for code blocks.
- Added tidyGetMessageCode() to message API. Despite the huge diff, this is the
only externally-visible change, other than removing some enums (but not their
values!).
- Passing `next` tests on Mac, Linux, Win10.
- tidyDetectedHtmlVersion()
- tidyDetectedXhtml()
- added two new fields to W3C_Doctypes[] in order to simplify this.
- added TY_(HTMLVersionNumberFromCode)() to enable lookup.
- Implement tidyDetectedGenericXml()
- Added a warning message if an XML declaration exists but the document is not
XHTML.
- Remove dead commented code.
- Updated POs and POT. Headers not affected, but translators should check
their translations.
- Testing is clean on Mac OS X, Ubuntu 16.04, and Windows 10.
This is a rather large refactoring of Tidy's messaging system. This was done
mostly to allow non-C libraries that cannot adequately take advantage of
arg_lists a chance to query report filter information for information related
to arguments used in constructing an error message.
Three main goals were in mind for this project:
- Don't change the contents of Tidy's existing output sinks. This will ensure
that changes do no affect console Tidy users, or LibTidy users who use the
output sinks directly. This was accomplished 100% other than some improved
cosmetics in the output. See tidy-html5-tests repository, the `refactor` and
`more_messages_changes` branches for these minor diffs.
- Provide an API that is simple and also extensible without having to write new
error filters all the time. This was accomplished by adding the new message
callback `TidyMessageCallback` that provides callback functions an opaque
object representing the message, and an API to query the message for wanted
details. With this, we should never have to add a new callback routine again,
as additional API can simply be written against the opaque object.
- The API should work the same as the rest of LibTidy's API in that it's
consistent and only uses simple types with wide interoperability with other
languages. Thanks to @gagern who suggested the model for the API in #409.
Although the API uses the "Tidy" way off accessing data via an iterator
rather than an index, this can be easily abstracted in the target language.
There are two *major* API breaking changes:
- Removed TidyReportFilter2
- This was only used by one application in the entire world, and was a hacky
kludge that served its purpose. TidyReportCallback (né TidyReportFilter3)
is much better. If, for some reason, this affects you, I recommend using
TidyReportCallback instead. It's a minor change for your application.
- Renamed TidyReportFilter3 to TidyReportCallback
- This name is much more semantic, and much more sensible in light of
improved callback system. As the name implies, it remains capable of
*only* receiving callbacks for Tidy "reports."
Introducing TidyMessageCallback, and a new message interrogation API.
- As its name implies, it is able to capture (and optionally suppress) *all*
of Tidy's output, including the dialogue messages that never make it to
the existing report filters.
- Provides an opaque `TidyMessage` and an API that can be used to query against
it to find the juicy goodness inside.
- For example, `tidyGetMessageOutput( tmessage )` will return the complete,
localized message.
- Another example, `tidyGetMessageLine( tmessage )` will return the line the
message applies to.
- You can also get information about the individual arguments that make up a
message. By using the `tidyGetMessageArguments( tmessage )` itorator and
`tidyGetNextMessageArgument` you will obtain an opaque `TidyMessageArgument`
which has its own interrogation API. For example:
- tidyGetArgType( tmessage, &iterator );
- tidyGetArgFormat( tmessage, &iterator );
- tidyGetArgValueString( tmessage, &iterator );
- …and so on.
Other major changes include refactoring `messages.c` to use the new message
"object" directly when emitting messages to the console or output sinks. This
allowed replacement of a lot of specialized functions with generalized ones.
Some of this generalizing involved modifications to the `language_xx.h` header
files, and these are all positive improvements even without the above changes.
- Updated strings files to match.
- Inhibit internal options from being output via the iterator. Internals should
never have the chance to be exposed if they shouldn't be use.
- Added tidySetEmacsFile() and TidyGetEmacsFile() to the public API, and use it
instead of secret API to set the filename in the console application.
The end result is that `gnu-emacs-file` (and also `doctype-mode`) officially no
longer exist to CLI users nor to API users, and tidy console behaves properly
by using a published API to set the filename for emacs.
- 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.
These services can only be used when there is a document loaded, ie a
lexer created. But really should not be calling a Clean and Repair
service with no doc!
This is a MUCH SANER approach to what I was trying to do (now that I screwed up enough internals to understand some of them!
At this point there are zero exit state reversions, and zero markup reversions! There are still 21 errout reversions; I'll
annotate and adjust as necessary.
