- Prevent the message filter from missing possible messages due to dispered
control.
- Single decision point for the types of messages to be output given current
conditions and options settings.
- Change default value of `--fix-bad-comments` to `no`.
- Ensure that when _not_ fixing, nothing is actually fixed.
- Ensure that when fixing, initial adjacent hyphens actually are fixed.
- Issue tidyinfo for all fixes made.
- Issue tidywarning when when not making fixes for non-HTML5 doctypes.
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.
Note that there are several regressions in the accessibility test suit that
are not related to output messages. These are a result of previous work, and
these results should be updated in the test suite when this item is merged.
reflects such. Some fleshed in report formatters are included with cases for
several of Tidy's reports, but nothing is yet enabled. All reporting is status
quo, and this is just a bunch of dead code at this point.
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.
Add option TidyStyleTags, --fix-style-tags, Bool, to turn off
this action.
Add warning messages MOVED_STYLE_TO_HEAD, and FOUND_STYLE_IN_BODY.
Fully iterate ALL nodes in the body, in search of style tags...
Changes to be committed:
modified: include/tidyenum.h
modified: src/clean.c
modified: src/config.c
modified: src/language_en.h
modified: src/message.c
in #352, but I'm worried that there's some over-reach here.
Currently only implemented as a warning, with no switch to turn it off, which
maintains current behavior other than the warning.
In general, we're treating any string as a complete URL, rather than breaking
URL's into component parts. Thus the `IsURLCodePoint()` check includes a few
other generic characters that strictly speaking aren't valid codepoints, but
are valid as escape characters and delimiters.
When addressing #338, I ran into a similar situation in not having a built-in
method to separate path components (although a simple generalized solution was
good enough in that case).
Thus without introducing a new structure and functions to deconstruct a URL
into scheme, authority, path, parameters, etc., some variation of this patch
will have to be used to address #352.
