2017-02-13 19:29:47 +00:00
|
|
|
/* message.c -- General Message Writing Routines
|
2016-01-15 04:06:15 +00:00
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
(c) 1998-2017 (W3C) MIT, ERCIM, Keio University, University of
|
|
|
|
|
Toronto, HTACG
|
|
|
|
|
See tidy.h for the copyright notice.
|
2016-01-15 04:06:15 +00:00
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
#include "message.h"
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
#include "messageobj.h"
|
2017-03-16 20:46:01 +00:00
|
|
|
#include "limits.h"
|
2016-01-15 04:06:15 +00:00
|
|
|
#include "tidy-int.h"
|
|
|
|
|
#include "lexer.h"
|
|
|
|
|
#include "streamio.h"
|
|
|
|
|
#include "tmbstr.h"
|
|
|
|
|
#include "utf8.h"
|
|
|
|
|
#include "version.h"
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
|
|
|
|
|
/*********************************************************************
|
|
|
|
|
* Release Information
|
|
|
|
|
*********************************************************************/
|
2016-01-15 04:06:15 +00:00
|
|
|
|
|
|
|
|
ctmbstr TY_(ReleaseDate)(void)
|
|
|
|
|
{
|
|
|
|
|
return TY_(release_date);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
ctmbstr TY_(tidyLibraryVersion)(void)
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
2017-02-13 19:29:47 +00:00
|
|
|
return TY_(library_version);
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
/*********************************************************************
|
|
|
|
|
* General Message Utility Functions
|
|
|
|
|
*********************************************************************/
|
2016-01-15 04:06:15 +00:00
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
/* Returns the given node's tag as a string. */
|
|
|
|
|
static char* TagToString(Node* tag, char* buf, size_t count)
|
|
|
|
|
{
|
|
|
|
|
*buf = 0;
|
|
|
|
|
if (tag)
|
|
|
|
|
{
|
|
|
|
|
if (TY_(nodeIsElement)(tag))
|
|
|
|
|
TY_(tmbsnprintf)(buf, count, "<%s>", tag->element);
|
|
|
|
|
else if (tag->type == EndTag)
|
|
|
|
|
TY_(tmbsnprintf)(buf, count, "</%s>", tag->element);
|
|
|
|
|
else if (tag->type == DocTypeTag)
|
|
|
|
|
TY_(tmbsnprintf)(buf, count, "<!DOCTYPE>");
|
|
|
|
|
else if (tag->type == TextNode)
|
|
|
|
|
TY_(tmbsnprintf)(buf, count, "%s", tidyLocalizedString(STRING_PLAIN_TEXT));
|
|
|
|
|
else if (tag->type == XmlDecl)
|
|
|
|
|
TY_(tmbsnprintf)(buf, count, "%s", tidyLocalizedString(STRING_XML_DECLARATION));
|
|
|
|
|
else if (tag->element)
|
|
|
|
|
TY_(tmbsnprintf)(buf, count, "%s", tag->element);
|
|
|
|
|
}
|
|
|
|
|
return buf + TY_(tmbstrlen)(buf);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
/* Convert an integer to a string. */
|
2017-02-13 19:29:47 +00:00
|
|
|
static void NtoS(int n, tmbstr str)
|
|
|
|
|
{
|
|
|
|
|
tmbchar buf[40];
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0;; ++i)
|
|
|
|
|
{
|
|
|
|
|
buf[i] = (tmbchar)( (n % 10) + '0' );
|
|
|
|
|
|
|
|
|
|
n = n / 10;
|
|
|
|
|
|
|
|
|
|
if (n == 0)
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
n = i;
|
|
|
|
|
|
|
|
|
|
while (i >= 0)
|
|
|
|
|
{
|
|
|
|
|
str[n-i] = buf[i];
|
|
|
|
|
--i;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
str[n+1] = '\0';
|
|
|
|
|
}
|
|
|
|
|
|
2016-01-15 04:06:15 +00:00
|
|
|
|
2017-09-02 16:54:02 +00:00
|
|
|
/* Get an HTML version string */
|
|
|
|
|
static ctmbstr HTMLVersion( TidyDocImpl* doc )
|
|
|
|
|
{
|
|
|
|
|
uint versionEmitted = doc->lexer->versionEmitted;
|
|
|
|
|
uint declared = doc->lexer->doctype;
|
|
|
|
|
uint version = versionEmitted == 0 ? declared : versionEmitted;
|
|
|
|
|
ctmbstr result = TY_(HTMLVersionNameFromCode)(version, 0);
|
|
|
|
|
if (!result)
|
|
|
|
|
result = tidyLocalizedString(STRING_HTML_PROPRIETARY);
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
/*********************************************************************
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
* Message Writing Functions
|
|
|
|
|
* These funtions provide final, formatted output to the output sink.
|
2017-02-13 19:29:47 +00:00
|
|
|
*********************************************************************/
|
|
|
|
|
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
|
|
|
|
|
/* Writes messages to the output sink unless they are suppressed by one of the
|
|
|
|
|
** message callback filters, or suppressed by the configuration settings.
|
|
|
|
|
** Report messages are messages that are included in the "error table," and
|
|
|
|
|
** dialogue messages are any other output that Tidy traditionally emits.
|
2017-02-13 19:29:47 +00:00
|
|
|
*/
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
static void messageOut( TidyMessageImpl *message )
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
TidyDocImpl *doc;
|
2017-09-07 01:25:19 +00:00
|
|
|
Bool go = yes;
|
2016-01-15 04:06:15 +00:00
|
|
|
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
if ( !message )
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
doc = message->tidyDoc;
|
|
|
|
|
|
|
|
|
|
/* The filter has had a chance to suppress *any* message from output. */
|
|
|
|
|
go = message->allowMessage;
|
|
|
|
|
|
2017-09-07 01:25:19 +00:00
|
|
|
/* Update the count of each report type. */
|
|
|
|
|
switch ( message->level )
|
|
|
|
|
{
|
|
|
|
|
case TidyInfo:
|
|
|
|
|
doc->infoMessages++;
|
|
|
|
|
break;
|
|
|
|
|
case TidyWarning:
|
|
|
|
|
doc->warnings++;
|
|
|
|
|
break;
|
|
|
|
|
case TidyConfig:
|
|
|
|
|
doc->optionErrors++;
|
|
|
|
|
break;
|
|
|
|
|
case TidyAccess:
|
|
|
|
|
doc->accessErrors++;
|
|
|
|
|
break;
|
|
|
|
|
case TidyError:
|
|
|
|
|
doc->errors++;
|
|
|
|
|
break;
|
|
|
|
|
case TidyBadDocument:
|
|
|
|
|
doc->docErrors++;
|
|
|
|
|
break;
|
|
|
|
|
case TidyFatal:
|
|
|
|
|
/* Ack! */
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-10 12:21:14 +00:00
|
|
|
/* Suppress report messages if they've been muted. */
|
|
|
|
|
go = go & !message->muted;
|
2017-10-08 14:47:03 +00:00
|
|
|
|
2017-09-07 01:25:19 +00:00
|
|
|
/* Suppress report messages if we've already reached the reporting limit. */
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
if ( message->level <= TidyFatal )
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
2017-09-07 01:25:19 +00:00
|
|
|
go = go & ( doc->errors < cfg(doc, TidyShowErrors) );
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
2017-10-20 12:52:37 +00:00
|
|
|
/* Let TidyQuiet silence a lot of things. */
|
|
|
|
|
if ( cfgBool( doc, TidyQuiet ) == yes )
|
2017-08-31 14:44:16 +00:00
|
|
|
{
|
2017-10-20 12:52:37 +00:00
|
|
|
go = go && message->code != STRING_DOCTYPE_GIVEN;
|
|
|
|
|
go = go && message->code != STRING_CONTENT_LOOKS;
|
|
|
|
|
go = go && message->code != STRING_NO_SYSID;
|
|
|
|
|
go = go && message->level != TidyDialogueInfo;
|
|
|
|
|
go = go && message->level != TidyConfig;
|
|
|
|
|
go = go && message->level != TidyInfo;
|
|
|
|
|
go = go && !(message->level >= TidyDialogueSummary &&
|
|
|
|
|
message->code != STRING_NEEDS_INTERVENTION);
|
2017-08-31 14:44:16 +00:00
|
|
|
}
|
|
|
|
|
|
2017-10-20 12:52:37 +00:00
|
|
|
/* Let !TidyShowInfo silence some things. */
|
|
|
|
|
if ( cfgBool( doc, TidyShowInfo ) == no )
|
2017-10-05 19:04:22 +00:00
|
|
|
{
|
2017-10-20 12:52:37 +00:00
|
|
|
go = go && message->level != TidyInfo;
|
2017-10-05 19:04:22 +00:00
|
|
|
|
2017-10-20 12:52:37 +00:00
|
|
|
/* Temporary; TidyShowInfo shouldn't affect TidyDialogueInfo, but
|
|
|
|
|
right now such messages are hidden until we granularize the
|
|
|
|
|
output controls. */
|
|
|
|
|
go = go && message->level != TidyDialogueInfo;
|
2017-10-05 19:04:22 +00:00
|
|
|
}
|
|
|
|
|
|
2017-10-20 12:52:37 +00:00
|
|
|
/* Let !TidyShowWarnings silence some things. */
|
|
|
|
|
if ( cfgBool( doc, TidyShowWarnings ) == no )
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
{
|
2017-10-20 12:52:37 +00:00
|
|
|
go = go && message->level != TidyWarning;
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
}
|
2017-02-13 19:29:47 +00:00
|
|
|
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
/* Output the message if applicable. */
|
|
|
|
|
if ( go )
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
2016-03-23 18:42:03 +00:00
|
|
|
TidyOutputSink *outp = &doc->errout->sink;
|
2016-01-15 04:06:15 +00:00
|
|
|
ctmbstr cp;
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
byte b = '\0';
|
|
|
|
|
for ( cp = message->messageOutput; *cp; ++cp )
|
2016-03-23 18:42:03 +00:00
|
|
|
{
|
|
|
|
|
b = (*cp & 0xff);
|
|
|
|
|
if (b == (byte)'\n')
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
TY_(WriteChar)( b, doc->errout ); /* for EOL translation */
|
2016-03-23 18:42:03 +00:00
|
|
|
else
|
|
|
|
|
outp->putByte( outp->sinkData, b ); /* #383 - no encoding */
|
|
|
|
|
}
|
|
|
|
|
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
/* Always add a trailing newline. Reports require this, and dialogue
|
|
|
|
|
messages will be better spaced out without having to fill the
|
|
|
|
|
language file with superflous newlines. */
|
|
|
|
|
TY_(WriteChar)( '\n', doc->errout );
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
|
|
|
|
|
TY_(tidyMessageRelease)(message);
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
/*********************************************************************
|
2017-09-02 20:47:14 +00:00
|
|
|
* Report Formatting
|
|
|
|
|
* In order to provide a single, predictable reporting system, Tidy
|
|
|
|
|
* provides an extensible messaging system that provides most of the
|
|
|
|
|
* basic requirements for most reports, while permitting simple
|
|
|
|
|
* implementation of new reports in a flexible manner. By adding
|
|
|
|
|
* additional formatters, new messages can be added easily while
|
|
|
|
|
* maintaining Tidy's internal organization.
|
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Functions of this type will create new instances of TidyMessage specific to
|
|
|
|
|
** the type of report being emitted. Many messages share the same fomatter for
|
2017-09-07 01:25:19 +00:00
|
|
|
** messages, but new ones can be written as required. Please have a look at
|
|
|
|
|
** the existing formatters in order to determine if an existing signature is
|
|
|
|
|
** compatible with the report you wish to output before adding a new formatter.
|
|
|
|
|
** In particular, if an existing formatter provides most of the local variables
|
|
|
|
|
** required to populate your format string, try to use it.
|
2017-09-02 20:47:14 +00:00
|
|
|
*/
|
|
|
|
|
typedef TidyMessageImpl*(messageFormatter)(TidyDocImpl* doc, Node *element, Node *node, uint code, uint level, va_list args);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Forward declarations of messageFormatter functions. */
|
2017-09-04 21:35:57 +00:00
|
|
|
static messageFormatter formatAccessReport;
|
2017-09-02 20:47:14 +00:00
|
|
|
static messageFormatter formatAttributeReport;
|
2017-09-04 19:50:45 +00:00
|
|
|
static messageFormatter formatEncodingReport;
|
2017-09-02 20:47:14 +00:00
|
|
|
static messageFormatter formatStandard;
|
|
|
|
|
static messageFormatter formatStandardDynamic;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* This structure ties together for each report Code the default
|
|
|
|
|
** TidyReportLevel, the Formatter to be used to construct the message, and the
|
2017-09-07 01:25:19 +00:00
|
|
|
** next code to output, if applicable. Assuming an existing formatter can,
|
2017-09-02 20:47:14 +00:00
|
|
|
** this it makes it simple to output new reports, or to change report level by
|
|
|
|
|
** modifying this array.
|
|
|
|
|
*/
|
|
|
|
|
static struct _dispatchTable {
|
|
|
|
|
uint code; /**< The message code. */
|
|
|
|
|
TidyReportLevel level; /**< The default TidyReportLevel of the message. */
|
|
|
|
|
messageFormatter *handler; /**< The formatter for the report. */
|
|
|
|
|
uint next; /**< If multiple codes should be displayed, which is next? */
|
|
|
|
|
} dispatchTable[] = {
|
|
|
|
|
{ ADDED_MISSING_CHARSET, TidyInfo, formatStandard },
|
|
|
|
|
{ ANCHOR_NOT_UNIQUE, TidyWarning, formatAttributeReport },
|
2017-09-04 19:28:08 +00:00
|
|
|
{ APOS_UNDEFINED, TidyWarning, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ ATTR_VALUE_NOT_LCASE, TidyWarning, formatAttributeReport },
|
2017-09-02 21:29:56 +00:00
|
|
|
{ ATTRIBUTE_VALUE_REPLACED, TidyInfo, formatAttributeReport },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ ATTRIBUTE_IS_NOT_ALLOWED, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ BACKSLASH_IN_URI, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ BAD_ATTRIBUTE_VALUE_REPLACED, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ BAD_ATTRIBUTE_VALUE, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ BAD_CDATA_CONTENT, TidyWarning, formatStandard },
|
|
|
|
|
{ BAD_SUMMARY_HTML5, TidyWarning, formatStandard },
|
2017-09-04 20:38:07 +00:00
|
|
|
{ BAD_SURROGATE_LEAD, TidyWarning, formatStandard },
|
|
|
|
|
{ BAD_SURROGATE_PAIR, TidyWarning, formatStandard },
|
|
|
|
|
{ BAD_SURROGATE_TAIL, TidyWarning, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ CANT_BE_NESTED, TidyWarning, formatStandard },
|
|
|
|
|
{ COERCE_TO_ENDTAG, TidyWarning, formatStandard },
|
|
|
|
|
{ CONTENT_AFTER_BODY, TidyWarning, formatStandard },
|
2017-09-04 15:44:54 +00:00
|
|
|
{ CUSTOM_TAG_DETECTED, TidyInfo, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ DISCARDING_UNEXPECTED, 0, formatStandardDynamic },
|
|
|
|
|
{ DOCTYPE_AFTER_TAGS, TidyWarning, formatStandard },
|
|
|
|
|
{ DUPLICATE_FRAMESET, TidyError, formatStandard },
|
|
|
|
|
{ ELEMENT_NOT_EMPTY, TidyWarning, formatStandard },
|
|
|
|
|
{ ELEMENT_VERS_MISMATCH_ERROR, TidyError, formatStandard },
|
|
|
|
|
{ ELEMENT_VERS_MISMATCH_WARN, TidyWarning, formatStandard },
|
2017-09-04 20:12:01 +00:00
|
|
|
{ ENCODING_MISMATCH, TidyWarning, formatEncodingReport },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ ESCAPED_ILLEGAL_URI, TidyWarning, formatAttributeReport },
|
2017-09-04 15:35:49 +00:00
|
|
|
{ FILE_CANT_OPEN, TidyBadDocument, formatStandard },
|
|
|
|
|
{ FILE_CANT_OPEN_CFG, TidyBadDocument, formatStandard },
|
|
|
|
|
{ FILE_NOT_FILE, TidyBadDocument, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ FIXED_BACKSLASH, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ FOUND_STYLE_IN_BODY, TidyWarning, formatStandard },
|
|
|
|
|
{ ID_NAME_MISMATCH, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ ILLEGAL_NESTING, TidyWarning, formatStandard },
|
|
|
|
|
{ ILLEGAL_URI_CODEPOINT, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ ILLEGAL_URI_REFERENCE, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ INSERTING_AUTO_ATTRIBUTE, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ INSERTING_TAG, TidyWarning, formatStandard },
|
|
|
|
|
{ INVALID_ATTRIBUTE, TidyWarning, formatAttributeReport },
|
2017-09-04 20:12:01 +00:00
|
|
|
{ INVALID_NCR, TidyWarning, formatEncodingReport },
|
|
|
|
|
{ INVALID_SGML_CHARS, TidyWarning, formatEncodingReport },
|
|
|
|
|
{ INVALID_UTF8, TidyWarning, formatEncodingReport },
|
|
|
|
|
{ INVALID_UTF16, TidyWarning, formatEncodingReport },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ INVALID_XML_ID, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ JOINING_ATTRIBUTE, TidyWarning, formatAttributeReport },
|
2017-09-24 22:15:40 +00:00
|
|
|
{ MALFORMED_COMMENT, TidyInfo, formatStandard },
|
|
|
|
|
{ MALFORMED_COMMENT_EOS, TidyError, formatStandard },
|
|
|
|
|
{ MALFORMED_COMMENT_DROPPING, TidyWarning, formatStandard },
|
|
|
|
|
{ MALFORMED_COMMENT_WARN, TidyWarning, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ MALFORMED_DOCTYPE, TidyWarning, formatStandard },
|
|
|
|
|
{ MISMATCHED_ATTRIBUTE_ERROR, TidyError, formatAttributeReport },
|
|
|
|
|
{ MISMATCHED_ATTRIBUTE_WARN, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ MISSING_ATTR_VALUE, TidyWarning, formatAttributeReport },
|
2017-09-04 20:12:01 +00:00
|
|
|
{ MISSING_ATTRIBUTE, TidyWarning, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ MISSING_DOCTYPE, TidyWarning, formatStandard },
|
|
|
|
|
{ MISSING_ENDTAG_BEFORE, TidyWarning, formatStandard },
|
|
|
|
|
{ MISSING_ENDTAG_FOR, TidyWarning, formatStandard },
|
2017-09-29 18:46:17 +00:00
|
|
|
{ MISSING_ENDTAG_OPTIONAL, TidyInfo, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ MISSING_IMAGEMAP, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ MISSING_QUOTEMARK, TidyWarning, formatAttributeReport },
|
2017-09-22 23:01:31 +00:00
|
|
|
{ MISSING_QUOTEMARK_OPEN, TidyInfo, formatAttributeReport },
|
2017-09-04 19:28:08 +00:00
|
|
|
{ MISSING_SEMICOLON_NCR, TidyWarning, formatStandard },
|
|
|
|
|
{ MISSING_SEMICOLON, TidyWarning, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ MISSING_STARTTAG, TidyWarning, formatStandard },
|
|
|
|
|
{ MISSING_TITLE_ELEMENT, TidyWarning, formatStandard },
|
|
|
|
|
{ MOVED_STYLE_TO_HEAD, TidyWarning, formatStandard },
|
|
|
|
|
{ NESTED_EMPHASIS, TidyWarning, formatStandard },
|
|
|
|
|
{ NESTED_QUOTATION, TidyWarning, formatStandard },
|
|
|
|
|
{ NEWLINE_IN_URI, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ NOFRAMES_CONTENT, TidyWarning, formatStandard },
|
|
|
|
|
{ NON_MATCHING_ENDTAG, TidyWarning, formatStandard },
|
|
|
|
|
{ OBSOLETE_ELEMENT, TidyWarning, formatStandard },
|
2017-10-07 15:04:18 +00:00
|
|
|
{ OPTION_REMOVED, TidyConfig, formatStandard },
|
|
|
|
|
{ OPTION_REMOVED_APPLIED, TidyConfig, formatStandard },
|
|
|
|
|
{ OPTION_REMOVED_UNAPPLIED, TidyConfig, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ PREVIOUS_LOCATION, TidyInfo, formatStandard },
|
|
|
|
|
{ PROPRIETARY_ATTR_VALUE, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ PROPRIETARY_ATTRIBUTE, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ PROPRIETARY_ELEMENT, TidyWarning, formatStandard },
|
|
|
|
|
{ REMOVED_HTML5, TidyWarning, formatStandard },
|
|
|
|
|
{ REPEATED_ATTRIBUTE, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ REPLACING_ELEMENT, TidyWarning, formatStandard },
|
|
|
|
|
{ REPLACING_UNEX_ELEMENT, TidyWarning, formatStandard },
|
|
|
|
|
{ SPACE_PRECEDING_XMLDECL, TidyWarning, formatStandard },
|
2017-10-08 14:47:03 +00:00
|
|
|
{ STRING_ARGUMENT_BAD, TidyConfig, formatStandard },
|
2017-09-08 01:06:44 +00:00
|
|
|
{ STRING_CONTENT_LOOKS, TidyInfo, formatStandard }, /* reportMarkupVersion() */
|
|
|
|
|
{ STRING_DOCTYPE_GIVEN, TidyInfo, formatStandard }, /* reportMarkupVersion() */
|
2017-09-04 15:40:34 +00:00
|
|
|
{ STRING_MISSING_MALFORMED, TidyConfig, formatStandard },
|
2017-10-10 12:21:14 +00:00
|
|
|
{ STRING_MUTING_TYPE, TidyConfig, formatStandard },
|
2017-09-08 01:06:44 +00:00
|
|
|
{ STRING_NO_SYSID, TidyInfo, formatStandard }, /* reportMarkupVersion() */
|
2017-09-04 20:38:07 +00:00
|
|
|
{ STRING_UNKNOWN_OPTION, TidyConfig, formatStandard },
|
2017-09-29 14:42:21 +00:00
|
|
|
{ SUSPECTED_MISSING_QUOTE, TidyWarning, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ TAG_NOT_ALLOWED_IN, TidyWarning, formatStandard, PREVIOUS_LOCATION },
|
|
|
|
|
{ TOO_MANY_ELEMENTS_IN, TidyWarning, formatStandard, PREVIOUS_LOCATION },
|
|
|
|
|
{ TOO_MANY_ELEMENTS, TidyWarning, formatStandard },
|
|
|
|
|
{ TRIM_EMPTY_ELEMENT, TidyWarning, formatStandard },
|
2017-09-04 19:28:08 +00:00
|
|
|
{ UNESCAPED_AMPERSAND, TidyWarning, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ UNEXPECTED_END_OF_FILE_ATTR, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ UNEXPECTED_END_OF_FILE, TidyWarning, formatStandard },
|
|
|
|
|
{ UNEXPECTED_ENDTAG_IN, TidyError, formatStandard },
|
|
|
|
|
{ UNEXPECTED_ENDTAG, TidyWarning, formatStandard },
|
|
|
|
|
{ UNEXPECTED_ENDTAG_ERR, TidyError, formatStandard },
|
|
|
|
|
{ UNEXPECTED_EQUALSIGN, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ UNEXPECTED_GT, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ UNEXPECTED_QUOTEMARK, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ UNKNOWN_ELEMENT_LOOKS_CUSTOM, TidyError, formatStandard },
|
|
|
|
|
{ UNKNOWN_ELEMENT, TidyError, formatStandard },
|
2017-09-04 19:28:08 +00:00
|
|
|
{ UNKNOWN_ENTITY, TidyWarning, formatStandard },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ USING_BR_INPLACE_OF, TidyWarning, formatStandard },
|
2017-09-04 20:12:01 +00:00
|
|
|
{ VENDOR_SPECIFIC_CHARS, TidyWarning, formatEncodingReport },
|
2017-09-02 20:47:14 +00:00
|
|
|
{ WHITE_IN_URI, TidyWarning, formatAttributeReport },
|
|
|
|
|
{ XML_DECLARATION_DETECTED, TidyWarning, formatStandard },
|
|
|
|
|
{ XML_ID_SYNTAX, TidyWarning, formatAttributeReport },
|
2017-09-04 21:35:57 +00:00
|
|
|
|
|
|
|
|
{ APPLET_MISSING_ALT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ AREA_MISSING_ALT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ ASCII_REQUIRES_DESCRIPTION, TidyAccess, formatAccessReport },
|
|
|
|
|
{ ASSOCIATE_LABELS_EXPLICITLY, TidyAccess, formatAccessReport },
|
|
|
|
|
{ ASSOCIATE_LABELS_EXPLICITLY_FOR, TidyAccess, formatAccessReport },
|
|
|
|
|
{ ASSOCIATE_LABELS_EXPLICITLY_ID, TidyAccess, formatAccessReport },
|
|
|
|
|
{ AUDIO_MISSING_TEXT_AIFF, TidyAccess, formatAccessReport },
|
|
|
|
|
{ AUDIO_MISSING_TEXT_AU, TidyAccess, formatAccessReport },
|
|
|
|
|
{ AUDIO_MISSING_TEXT_RA, TidyAccess, formatAccessReport },
|
|
|
|
|
{ AUDIO_MISSING_TEXT_RM, TidyAccess, formatAccessReport },
|
|
|
|
|
{ AUDIO_MISSING_TEXT_SND, TidyAccess, formatAccessReport },
|
|
|
|
|
{ AUDIO_MISSING_TEXT_WAV, TidyAccess, formatAccessReport },
|
|
|
|
|
{ COLOR_CONTRAST_ACTIVE_LINK, TidyAccess, formatAccessReport },
|
|
|
|
|
{ COLOR_CONTRAST_LINK, TidyAccess, formatAccessReport },
|
|
|
|
|
{ COLOR_CONTRAST_TEXT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ COLOR_CONTRAST_VISITED_LINK, TidyAccess, formatAccessReport },
|
|
|
|
|
{ DATA_TABLE_MISSING_HEADERS, TidyAccess, formatAccessReport },
|
|
|
|
|
{ DATA_TABLE_MISSING_HEADERS_COLUMN, TidyAccess, formatAccessReport },
|
|
|
|
|
{ DATA_TABLE_MISSING_HEADERS_ROW, TidyAccess, formatAccessReport },
|
|
|
|
|
{ DATA_TABLE_REQUIRE_MARKUP_COLUMN_HEADERS, TidyAccess, formatAccessReport },
|
|
|
|
|
{ DATA_TABLE_REQUIRE_MARKUP_ROW_HEADERS, TidyAccess, formatAccessReport },
|
|
|
|
|
{ DOCTYPE_MISSING, TidyAccess, formatAccessReport },
|
|
|
|
|
{ ENSURE_PROGRAMMATIC_OBJECTS_ACCESSIBLE_APPLET, TidyAccess, formatAccessReport },
|
|
|
|
|
{ ENSURE_PROGRAMMATIC_OBJECTS_ACCESSIBLE_EMBED, TidyAccess, formatAccessReport },
|
|
|
|
|
{ ENSURE_PROGRAMMATIC_OBJECTS_ACCESSIBLE_OBJECT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ ENSURE_PROGRAMMATIC_OBJECTS_ACCESSIBLE_SCRIPT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ FRAME_MISSING_LONGDESC, TidyAccess, formatAccessReport },
|
|
|
|
|
{ FRAME_MISSING_NOFRAMES, TidyAccess, formatAccessReport },
|
|
|
|
|
{ FRAME_MISSING_TITLE, TidyAccess, formatAccessReport },
|
|
|
|
|
{ FRAME_SRC_INVALID, TidyAccess, formatAccessReport },
|
|
|
|
|
{ FRAME_TITLE_INVALID_NULL, TidyAccess, formatAccessReport },
|
|
|
|
|
{ FRAME_TITLE_INVALID_SPACES, TidyAccess, formatAccessReport },
|
|
|
|
|
{ HEADER_USED_FORMAT_TEXT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ HEADERS_IMPROPERLY_NESTED, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMAGE_MAP_SERVER_SIDE_REQUIRES_CONVERSION, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_ALT_SUSPICIOUS_FILE_SIZE, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_ALT_SUSPICIOUS_FILENAME, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_ALT_SUSPICIOUS_PLACEHOLDER, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_ALT_SUSPICIOUS_TOO_LONG, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_BUTTON_MISSING_ALT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_MAP_CLIENT_MISSING_TEXT_LINKS, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_MAP_SERVER_REQUIRES_TEXT_LINKS, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_MISSING_ALT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_MISSING_DLINK, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_MISSING_LONGDESC, TidyAccess, formatAccessReport },
|
|
|
|
|
{ IMG_MISSING_LONGDESC_DLINK, TidyAccess, formatAccessReport },
|
|
|
|
|
{ INFORMATION_NOT_CONVEYED_APPLET, TidyAccess, formatAccessReport },
|
|
|
|
|
{ INFORMATION_NOT_CONVEYED_IMAGE, TidyAccess, formatAccessReport },
|
|
|
|
|
{ INFORMATION_NOT_CONVEYED_INPUT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ INFORMATION_NOT_CONVEYED_OBJECT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ INFORMATION_NOT_CONVEYED_SCRIPT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LANGUAGE_INVALID, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LANGUAGE_NOT_IDENTIFIED, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LAYOUT_TABLE_INVALID_MARKUP, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LAYOUT_TABLES_LINEARIZE_PROPERLY, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LINK_TEXT_MISSING, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LINK_TEXT_NOT_MEANINGFUL, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LINK_TEXT_NOT_MEANINGFUL_CLICK_HERE, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LINK_TEXT_TOO_LONG, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LIST_USAGE_INVALID_LI, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LIST_USAGE_INVALID_OL, TidyAccess, formatAccessReport },
|
|
|
|
|
{ LIST_USAGE_INVALID_UL, TidyAccess, formatAccessReport },
|
|
|
|
|
{ METADATA_MISSING, TidyAccess, formatAccessReport },
|
|
|
|
|
{ METADATA_MISSING_REDIRECT_AUTOREFRESH, TidyAccess, formatAccessReport },
|
|
|
|
|
{ MULTIMEDIA_REQUIRES_TEXT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ NEW_WINDOWS_REQUIRE_WARNING_BLANK, TidyAccess, formatAccessReport },
|
|
|
|
|
{ NEW_WINDOWS_REQUIRE_WARNING_NEW, TidyAccess, formatAccessReport },
|
|
|
|
|
{ NOFRAMES_INVALID_CONTENT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ NOFRAMES_INVALID_LINK, TidyAccess, formatAccessReport },
|
|
|
|
|
{ NOFRAMES_INVALID_NO_VALUE, TidyAccess, formatAccessReport },
|
|
|
|
|
{ OBJECT_MISSING_ALT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ POTENTIAL_HEADER_BOLD, TidyAccess, formatAccessReport },
|
|
|
|
|
{ POTENTIAL_HEADER_ITALICS, TidyAccess, formatAccessReport },
|
|
|
|
|
{ POTENTIAL_HEADER_UNDERLINE, TidyAccess, formatAccessReport },
|
|
|
|
|
{ PROGRAMMATIC_OBJECTS_REQUIRE_TESTING_APPLET, TidyAccess, formatAccessReport },
|
|
|
|
|
{ PROGRAMMATIC_OBJECTS_REQUIRE_TESTING_EMBED, TidyAccess, formatAccessReport },
|
|
|
|
|
{ PROGRAMMATIC_OBJECTS_REQUIRE_TESTING_OBJECT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ PROGRAMMATIC_OBJECTS_REQUIRE_TESTING_SCRIPT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REMOVE_AUTO_REDIRECT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REMOVE_AUTO_REFRESH, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REMOVE_BLINK_MARQUEE, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REMOVE_FLICKER_ANIMATED_GIF, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REMOVE_FLICKER_APPLET, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REMOVE_FLICKER_EMBED, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REMOVE_FLICKER_OBJECT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REMOVE_FLICKER_SCRIPT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REPLACE_DEPRECATED_HTML_APPLET, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REPLACE_DEPRECATED_HTML_BASEFONT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REPLACE_DEPRECATED_HTML_CENTER, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REPLACE_DEPRECATED_HTML_DIR, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REPLACE_DEPRECATED_HTML_FONT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REPLACE_DEPRECATED_HTML_ISINDEX, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REPLACE_DEPRECATED_HTML_MENU, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REPLACE_DEPRECATED_HTML_S, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REPLACE_DEPRECATED_HTML_STRIKE, TidyAccess, formatAccessReport },
|
|
|
|
|
{ REPLACE_DEPRECATED_HTML_U, TidyAccess, formatAccessReport },
|
|
|
|
|
{ SCRIPT_MISSING_NOSCRIPT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ SCRIPT_NOT_KEYBOARD_ACCESSIBLE_ON_CLICK, TidyAccess, formatAccessReport },
|
|
|
|
|
{ SCRIPT_NOT_KEYBOARD_ACCESSIBLE_ON_MOUSE_DOWN, TidyAccess, formatAccessReport },
|
|
|
|
|
{ SCRIPT_NOT_KEYBOARD_ACCESSIBLE_ON_MOUSE_MOVE, TidyAccess, formatAccessReport },
|
|
|
|
|
{ SCRIPT_NOT_KEYBOARD_ACCESSIBLE_ON_MOUSE_OUT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ SCRIPT_NOT_KEYBOARD_ACCESSIBLE_ON_MOUSE_OVER, TidyAccess, formatAccessReport },
|
|
|
|
|
{ SCRIPT_NOT_KEYBOARD_ACCESSIBLE_ON_MOUSE_UP, TidyAccess, formatAccessReport },
|
|
|
|
|
{ SKIPOVER_ASCII_ART, TidyAccess, formatAccessReport },
|
|
|
|
|
{ STYLE_SHEET_CONTROL_PRESENTATION, TidyAccess, formatAccessReport },
|
|
|
|
|
{ STYLESHEETS_REQUIRE_TESTING_LINK, TidyAccess, formatAccessReport },
|
|
|
|
|
{ STYLESHEETS_REQUIRE_TESTING_STYLE_ATTR, TidyAccess, formatAccessReport },
|
|
|
|
|
{ STYLESHEETS_REQUIRE_TESTING_STYLE_ELEMENT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TABLE_MAY_REQUIRE_HEADER_ABBR, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TABLE_MAY_REQUIRE_HEADER_ABBR_NULL, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TABLE_MAY_REQUIRE_HEADER_ABBR_SPACES, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TABLE_MISSING_CAPTION, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TABLE_MISSING_SUMMARY, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TABLE_SUMMARY_INVALID_NULL, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TABLE_SUMMARY_INVALID_PLACEHOLDER, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TABLE_SUMMARY_INVALID_SPACES, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TEXT_EQUIVALENTS_REQUIRE_UPDATING_APPLET, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TEXT_EQUIVALENTS_REQUIRE_UPDATING_OBJECT, TidyAccess, formatAccessReport },
|
|
|
|
|
{ TEXT_EQUIVALENTS_REQUIRE_UPDATING_SCRIPT, TidyAccess, formatAccessReport },
|
|
|
|
|
|
2017-09-02 20:47:14 +00:00
|
|
|
{ 0, 0, NULL }
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*********************************************************************
|
|
|
|
|
* Message Formatting
|
|
|
|
|
* These individual message formatters populate messages with the
|
|
|
|
|
* correct, pertinent data.
|
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
|
|
|
2017-09-07 01:25:19 +00:00
|
|
|
/* Provides formatting for the Attribute-related reports. This formatter
|
|
|
|
|
** should be reserved for messages generated by Tidy's accessibility module,
|
|
|
|
|
** even if the signature matches some unrelated report that you wish to
|
|
|
|
|
** generate.
|
|
|
|
|
*/
|
2017-09-04 21:35:57 +00:00
|
|
|
TidyMessageImpl *formatAccessReport(TidyDocImpl* doc, Node *element, Node *node, uint code, uint level, va_list args)
|
|
|
|
|
{
|
|
|
|
|
doc->badAccess |= BA_WAI;
|
2017-09-07 01:25:19 +00:00
|
|
|
|
|
|
|
|
/* Currently *all* cases are handled in the default, but maintain this
|
|
|
|
|
structure for possible future cases. */
|
|
|
|
|
switch (code)
|
|
|
|
|
{
|
|
|
|
|
default:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
2017-09-04 21:35:57 +00:00
|
|
|
}
|
|
|
|
|
|
2017-09-07 01:25:19 +00:00
|
|
|
/* Provides formatting for the Attribute-related reports. This formatter
|
|
|
|
|
** provides local variables that are used principally in the formats used for
|
|
|
|
|
** the attribute related reports.
|
|
|
|
|
*/
|
2017-09-02 20:47:14 +00:00
|
|
|
TidyMessageImpl *formatAttributeReport(TidyDocImpl* doc, Node *element, Node *node, uint code, uint level, va_list args)
|
|
|
|
|
{
|
|
|
|
|
AttVal *av = NULL;
|
2017-09-02 21:29:56 +00:00
|
|
|
char const *name = "NULL";
|
|
|
|
|
char const *value = "NULL";
|
2017-09-02 20:47:14 +00:00
|
|
|
char tagdesc[64];
|
|
|
|
|
|
|
|
|
|
TagToString(node, tagdesc, sizeof(tagdesc));
|
|
|
|
|
|
|
|
|
|
if ( ( av = va_arg(args, AttVal*) ) )
|
|
|
|
|
{
|
|
|
|
|
if (av->attribute)
|
|
|
|
|
name = av->attribute;
|
|
|
|
|
if (av->value)
|
|
|
|
|
value = av->value;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (code)
|
|
|
|
|
{
|
2017-09-22 23:01:31 +00:00
|
|
|
case MISSING_QUOTEMARK_OPEN:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, name );
|
|
|
|
|
|
2017-09-22 23:27:47 +00:00
|
|
|
case BACKSLASH_IN_URI:
|
2017-09-02 20:47:14 +00:00
|
|
|
case ESCAPED_ILLEGAL_URI:
|
|
|
|
|
case FIXED_BACKSLASH:
|
|
|
|
|
case ID_NAME_MISMATCH:
|
|
|
|
|
case ILLEGAL_URI_CODEPOINT:
|
|
|
|
|
case ILLEGAL_URI_REFERENCE:
|
|
|
|
|
case INVALID_XML_ID:
|
|
|
|
|
case MISSING_IMAGEMAP:
|
|
|
|
|
case MISSING_QUOTEMARK:
|
|
|
|
|
case NEWLINE_IN_URI:
|
|
|
|
|
case UNEXPECTED_EQUALSIGN:
|
|
|
|
|
case UNEXPECTED_GT:
|
|
|
|
|
case UNEXPECTED_QUOTEMARK:
|
|
|
|
|
case WHITE_IN_URI:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, tagdesc );
|
|
|
|
|
|
|
|
|
|
case ATTRIBUTE_IS_NOT_ALLOWED:
|
|
|
|
|
case JOINING_ATTRIBUTE:
|
|
|
|
|
case MISSING_ATTR_VALUE:
|
|
|
|
|
case PROPRIETARY_ATTRIBUTE:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, tagdesc, name );
|
|
|
|
|
|
2017-09-02 21:29:56 +00:00
|
|
|
case ATTRIBUTE_VALUE_REPLACED:
|
|
|
|
|
case BAD_ATTRIBUTE_VALUE:
|
2017-09-02 20:47:14 +00:00
|
|
|
case BAD_ATTRIBUTE_VALUE_REPLACED:
|
|
|
|
|
case INSERTING_AUTO_ATTRIBUTE:
|
|
|
|
|
case INVALID_ATTRIBUTE:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, tagdesc, name, value );
|
|
|
|
|
|
|
|
|
|
case MISMATCHED_ATTRIBUTE_ERROR:
|
|
|
|
|
case MISMATCHED_ATTRIBUTE_WARN:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, tagdesc, name, HTMLVersion(doc));
|
|
|
|
|
|
|
|
|
|
case ANCHOR_NOT_UNIQUE:
|
|
|
|
|
case ATTR_VALUE_NOT_LCASE:
|
|
|
|
|
case PROPRIETARY_ATTR_VALUE:
|
|
|
|
|
case XML_ID_SYNTAX:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, tagdesc, value );
|
|
|
|
|
|
|
|
|
|
case REPEATED_ATTRIBUTE:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, tagdesc, value, name );
|
|
|
|
|
|
|
|
|
|
case UNEXPECTED_END_OF_FILE_ATTR:
|
|
|
|
|
/* on end of file adjust reported position to end of input */
|
|
|
|
|
doc->lexer->lines = doc->docIn->curline;
|
|
|
|
|
doc->lexer->columns = doc->docIn->curcol;
|
|
|
|
|
return TY_(tidyMessageCreateWithLexer)(doc, code, level, tagdesc );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-09-04 19:50:45 +00:00
|
|
|
/* Provides report formatting *and* additional status settings for Tidy's
|
2017-09-07 01:25:19 +00:00
|
|
|
** encoding reports. Provides the local variables typically used for this type
|
|
|
|
|
** of report.
|
2017-09-04 19:50:45 +00:00
|
|
|
** @todo: These status changes probably SHOULD be made in the calling code;
|
|
|
|
|
** however these states are captured to generate future output, which may be
|
|
|
|
|
** useful here in the long run.
|
|
|
|
|
*/
|
|
|
|
|
TidyMessageImpl *formatEncodingReport(TidyDocImpl* doc, Node *element, Node *node, uint code, uint level, va_list args)
|
|
|
|
|
{
|
|
|
|
|
char buf[ 32 ] = {'\0'};
|
|
|
|
|
uint c = va_arg( args, uint );
|
|
|
|
|
Bool discarded = va_arg( args, Bool );
|
|
|
|
|
ctmbstr action = tidyLocalizedString(discarded ? STRING_DISCARDING : STRING_REPLACING);
|
|
|
|
|
|
|
|
|
|
switch (code)
|
|
|
|
|
{
|
|
|
|
|
case INVALID_NCR:
|
|
|
|
|
NtoS(c, buf);
|
|
|
|
|
doc->badChars |= BC_INVALID_NCR;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INVALID_SGML_CHARS:
|
|
|
|
|
NtoS(c, buf);
|
|
|
|
|
doc->badChars |= BC_INVALID_SGML_CHARS;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INVALID_UTF8:
|
|
|
|
|
TY_(tmbsnprintf)(buf, sizeof(buf), "U+%04X", c);
|
|
|
|
|
doc->badChars |= BC_INVALID_UTF8;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INVALID_UTF16:
|
|
|
|
|
TY_(tmbsnprintf)(buf, sizeof(buf), "U+%04X", c);
|
|
|
|
|
doc->badChars |= BC_INVALID_UTF16;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case VENDOR_SPECIFIC_CHARS:
|
|
|
|
|
NtoS(c, buf);
|
|
|
|
|
doc->badChars |= BC_VENDOR_SPECIFIC_CHARS;
|
|
|
|
|
break;
|
2017-09-04 20:12:01 +00:00
|
|
|
|
|
|
|
|
case ENCODING_MISMATCH:
|
|
|
|
|
doc->badChars |= BC_ENCODING_MISMATCH;
|
|
|
|
|
return TY_(tidyMessageCreateWithLexer)(doc,
|
|
|
|
|
code,
|
|
|
|
|
level,
|
|
|
|
|
TY_(CharEncodingName)(doc->docIn->encoding),
|
|
|
|
|
TY_(CharEncodingName)(c));
|
|
|
|
|
break;
|
2017-09-04 19:50:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return TY_(tidyMessageCreateWithLexer)(doc, code, level, action, buf );
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-09-04 15:44:54 +00:00
|
|
|
/* Provides general formatting for the majority of Tidy's reports. Because most
|
|
|
|
|
** reports use the same basic data derived from the element and node, this
|
|
|
|
|
** formatter covers the vast majority of Tidy's report messages. Note that this
|
|
|
|
|
** formatter guarantees the values of TidyReportLevel in the dispatchTable[].
|
2017-09-07 01:25:19 +00:00
|
|
|
** Some of the cases in this formatter start new contexts from the va_list
|
|
|
|
|
** when the required data is simple. For complex local variable needs, it may
|
|
|
|
|
** be preferred to write a new formatter.
|
2017-09-04 15:44:54 +00:00
|
|
|
*/
|
|
|
|
|
TidyMessageImpl *formatStandard(TidyDocImpl* doc, Node *element, Node *node, uint code, uint level, va_list args)
|
2017-09-02 20:47:14 +00:00
|
|
|
{
|
2017-09-04 15:44:54 +00:00
|
|
|
char nodedesc[ 256 ] = {0};
|
|
|
|
|
char elemdesc[ 256 ] = {0};
|
|
|
|
|
Node* rpt = ( element ? element : node );
|
2017-09-02 20:47:14 +00:00
|
|
|
|
2017-09-04 15:44:54 +00:00
|
|
|
TagToString(node, nodedesc, sizeof(nodedesc));
|
|
|
|
|
|
|
|
|
|
if ( element )
|
|
|
|
|
TagToString(element, elemdesc, sizeof(elemdesc));
|
2017-09-02 20:47:14 +00:00
|
|
|
|
2017-09-02 22:04:51 +00:00
|
|
|
switch ( code )
|
2017-09-02 20:47:14 +00:00
|
|
|
{
|
2017-09-02 22:04:51 +00:00
|
|
|
case CUSTOM_TAG_DETECTED:
|
2017-09-04 15:44:54 +00:00
|
|
|
{
|
|
|
|
|
ctmbstr tagtype;
|
2017-09-02 22:04:51 +00:00
|
|
|
switch ( cfg( doc, TidyUseCustomTags ) )
|
|
|
|
|
{
|
|
|
|
|
case TidyCustomBlocklevel:
|
|
|
|
|
tagtype = tidyLocalizedString( TIDYCUSTOMBLOCKLEVEL_STRING );
|
|
|
|
|
break;
|
|
|
|
|
case TidyCustomEmpty:
|
|
|
|
|
tagtype = tidyLocalizedString( TIDYCUSTOMEMPTY_STRING );
|
|
|
|
|
break;
|
|
|
|
|
case TidyCustomInline:
|
|
|
|
|
tagtype = tidyLocalizedString( TIDYCUSTOMINLINE_STRING );
|
|
|
|
|
break;
|
|
|
|
|
case TidyCustomPre:
|
|
|
|
|
default:
|
|
|
|
|
tagtype = tidyLocalizedString( TIDYCUSTOMPRE_STRING );
|
|
|
|
|
break;
|
|
|
|
|
}
|
2017-09-04 20:38:07 +00:00
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, element, code, level, elemdesc, tagtype );
|
2017-09-04 15:44:54 +00:00
|
|
|
}
|
2017-09-02 20:47:14 +00:00
|
|
|
|
2017-09-08 01:06:44 +00:00
|
|
|
case STRING_NO_SYSID:
|
|
|
|
|
return TY_(tidyMessageCreate)( doc, code, level );
|
|
|
|
|
|
2017-09-04 15:35:49 +00:00
|
|
|
case FILE_CANT_OPEN:
|
|
|
|
|
case FILE_CANT_OPEN_CFG:
|
|
|
|
|
case FILE_NOT_FILE:
|
2017-09-08 01:06:44 +00:00
|
|
|
case STRING_CONTENT_LOOKS:
|
|
|
|
|
case STRING_DOCTYPE_GIVEN:
|
2017-09-04 15:40:34 +00:00
|
|
|
case STRING_MISSING_MALFORMED:
|
2017-10-10 12:21:14 +00:00
|
|
|
case STRING_MUTING_TYPE:
|
2017-09-04 15:35:49 +00:00
|
|
|
{
|
2017-09-04 15:40:34 +00:00
|
|
|
ctmbstr str;
|
|
|
|
|
if ( (str = va_arg( args, ctmbstr)) )
|
|
|
|
|
return TY_(tidyMessageCreate)( doc, code, level, str );
|
2017-09-04 20:38:07 +00:00
|
|
|
|
|
|
|
|
} break;
|
2017-09-04 15:35:49 +00:00
|
|
|
|
2017-09-04 19:28:08 +00:00
|
|
|
case APOS_UNDEFINED:
|
|
|
|
|
case MISSING_SEMICOLON_NCR:
|
|
|
|
|
case MISSING_SEMICOLON:
|
|
|
|
|
case UNESCAPED_AMPERSAND:
|
|
|
|
|
case UNKNOWN_ENTITY:
|
|
|
|
|
{
|
|
|
|
|
ctmbstr entityname;
|
|
|
|
|
if ( !(entityname = va_arg( args, ctmbstr)) )
|
|
|
|
|
{
|
|
|
|
|
entityname = "NULL";
|
|
|
|
|
}
|
2017-09-04 20:38:07 +00:00
|
|
|
return TY_(tidyMessageCreateWithLexer)(doc, code, level, entityname);
|
2017-09-04 19:28:08 +00:00
|
|
|
}
|
|
|
|
|
|
2017-09-04 20:12:01 +00:00
|
|
|
case MISSING_ATTRIBUTE:
|
|
|
|
|
{
|
|
|
|
|
ctmbstr name;
|
|
|
|
|
if ( (name = va_arg( args, ctmbstr)) )
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, nodedesc, name );
|
2017-09-04 20:38:07 +00:00
|
|
|
} break;
|
|
|
|
|
|
|
|
|
|
case STRING_UNKNOWN_OPTION:
|
2017-10-07 15:04:18 +00:00
|
|
|
case OPTION_REMOVED:
|
2017-09-04 20:38:07 +00:00
|
|
|
{
|
|
|
|
|
ctmbstr str;
|
|
|
|
|
if ( (str = va_arg( args, ctmbstr)) )
|
|
|
|
|
return TY_(tidyMessageCreateWithLexer)(doc, code, level, str);
|
|
|
|
|
} break;
|
|
|
|
|
|
2017-10-07 15:04:18 +00:00
|
|
|
case OPTION_REMOVED_UNAPPLIED:
|
2017-10-08 14:47:03 +00:00
|
|
|
case STRING_ARGUMENT_BAD:
|
2017-10-07 15:04:18 +00:00
|
|
|
{
|
|
|
|
|
ctmbstr s1 = va_arg( args, ctmbstr );
|
|
|
|
|
ctmbstr s2 = va_arg( args, ctmbstr );
|
|
|
|
|
return TY_(tidyMessageCreateWithLexer)(doc, code, level, s1, s2);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case OPTION_REMOVED_APPLIED:
|
|
|
|
|
{
|
|
|
|
|
ctmbstr s1 = va_arg( args, ctmbstr );
|
|
|
|
|
ctmbstr s2 = va_arg( args, ctmbstr );
|
|
|
|
|
ctmbstr s3 = va_arg( args, ctmbstr );
|
|
|
|
|
return TY_(tidyMessageCreateWithLexer)(doc, code, level, s1, s2, s3);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-09-04 20:38:07 +00:00
|
|
|
case BAD_SURROGATE_LEAD:
|
|
|
|
|
case BAD_SURROGATE_PAIR:
|
|
|
|
|
case BAD_SURROGATE_TAIL:
|
|
|
|
|
{
|
|
|
|
|
uint c1 = va_arg( args, uint );
|
|
|
|
|
uint c2 = va_arg( args, uint );
|
|
|
|
|
return TY_(tidyMessageCreateWithLexer)(doc, code, level, c1, c2);
|
2017-09-04 20:12:01 +00:00
|
|
|
}
|
|
|
|
|
|
2017-09-02 20:47:14 +00:00
|
|
|
case SPACE_PRECEDING_XMLDECL:
|
|
|
|
|
/* @TODO: Should this be a TidyInfo "silent" fix? */
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level );
|
|
|
|
|
|
|
|
|
|
case CANT_BE_NESTED:
|
|
|
|
|
case NOFRAMES_CONTENT:
|
|
|
|
|
case USING_BR_INPLACE_OF:
|
|
|
|
|
/* Can we use `rpt` here? No; `element` has a value in every case. */
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, nodedesc );
|
|
|
|
|
|
|
|
|
|
case ELEMENT_VERS_MISMATCH_ERROR:
|
|
|
|
|
case ELEMENT_VERS_MISMATCH_WARN:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, nodedesc, HTMLVersion(doc) );
|
|
|
|
|
|
|
|
|
|
case TAG_NOT_ALLOWED_IN:
|
|
|
|
|
/* Can we use `rpt` here? No; `element` has a value in every case. */
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, nodedesc, element->element );
|
|
|
|
|
|
|
|
|
|
case INSERTING_TAG:
|
|
|
|
|
case MISSING_STARTTAG:
|
|
|
|
|
case TOO_MANY_ELEMENTS:
|
|
|
|
|
case UNEXPECTED_ENDTAG:
|
2017-09-04 15:24:48 +00:00
|
|
|
case UNEXPECTED_ENDTAG_ERR: /* generated by XML docs */
|
2017-09-02 20:47:14 +00:00
|
|
|
/* Can we use `rpt` here? No; `element` has a value in every case. */
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, node->element );
|
|
|
|
|
|
|
|
|
|
case UNEXPECTED_ENDTAG_IN:
|
|
|
|
|
/* Can we use `rpt` here? No; `element` has a value in every case. */
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, level, node->element, element->element );
|
|
|
|
|
|
|
|
|
|
case BAD_CDATA_CONTENT:
|
|
|
|
|
case CONTENT_AFTER_BODY:
|
|
|
|
|
case DOCTYPE_AFTER_TAGS:
|
|
|
|
|
case DUPLICATE_FRAMESET:
|
|
|
|
|
case MALFORMED_COMMENT:
|
2017-09-24 22:15:40 +00:00
|
|
|
case MALFORMED_COMMENT_DROPPING:
|
|
|
|
|
case MALFORMED_COMMENT_EOS:
|
|
|
|
|
case MALFORMED_COMMENT_WARN:
|
2017-09-02 20:47:14 +00:00
|
|
|
case MALFORMED_DOCTYPE:
|
|
|
|
|
case MISSING_DOCTYPE:
|
|
|
|
|
case MISSING_TITLE_ELEMENT:
|
|
|
|
|
case NESTED_QUOTATION:
|
|
|
|
|
case SUSPECTED_MISSING_QUOTE:
|
|
|
|
|
case XML_DECLARATION_DETECTED:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, rpt, code, level );
|
|
|
|
|
|
|
|
|
|
case ELEMENT_NOT_EMPTY:
|
2017-09-04 15:24:48 +00:00
|
|
|
case FOUND_STYLE_IN_BODY:
|
2017-09-02 20:47:14 +00:00
|
|
|
case ILLEGAL_NESTING:
|
2017-09-04 15:24:48 +00:00
|
|
|
case MOVED_STYLE_TO_HEAD:
|
2017-09-02 20:47:14 +00:00
|
|
|
case TRIM_EMPTY_ELEMENT:
|
|
|
|
|
case UNEXPECTED_END_OF_FILE:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, rpt, code, level, elemdesc );
|
|
|
|
|
|
|
|
|
|
case OBSOLETE_ELEMENT:
|
|
|
|
|
case REPLACING_ELEMENT:
|
|
|
|
|
case REPLACING_UNEX_ELEMENT:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, rpt, code, level, elemdesc, nodedesc );
|
|
|
|
|
|
2017-09-04 15:24:48 +00:00
|
|
|
case ADDED_MISSING_CHARSET:
|
2017-09-02 20:47:14 +00:00
|
|
|
case BAD_SUMMARY_HTML5:
|
|
|
|
|
case NESTED_EMPHASIS:
|
|
|
|
|
case PROPRIETARY_ELEMENT:
|
|
|
|
|
case REMOVED_HTML5:
|
|
|
|
|
case UNKNOWN_ELEMENT:
|
|
|
|
|
case UNKNOWN_ELEMENT_LOOKS_CUSTOM:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, rpt, code, level, nodedesc );
|
|
|
|
|
|
|
|
|
|
case MISSING_ENDTAG_FOR:
|
2017-09-29 18:46:17 +00:00
|
|
|
case MISSING_ENDTAG_OPTIONAL:
|
2017-09-02 20:47:14 +00:00
|
|
|
case PREVIOUS_LOCATION:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, rpt, code, level, element->element );
|
|
|
|
|
|
|
|
|
|
case MISSING_ENDTAG_BEFORE:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, rpt, code, level, element->element, nodedesc );
|
|
|
|
|
|
|
|
|
|
case COERCE_TO_ENDTAG:
|
|
|
|
|
case NON_MATCHING_ENDTAG:
|
|
|
|
|
case TOO_MANY_ELEMENTS_IN:
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, rpt, code, level, node->element, node->element );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Provides general formatting as formatStandard, except TidyReportLevel is set
|
|
|
|
|
** dynamically for these items as it cannot be predicted except at runtime.
|
|
|
|
|
*/
|
|
|
|
|
TidyMessageImpl *formatStandardDynamic(TidyDocImpl* doc, Node *element, Node *node, uint code, uint level, va_list args)
|
|
|
|
|
{
|
|
|
|
|
char nodedesc[ 256 ] = {0};
|
|
|
|
|
|
|
|
|
|
TagToString(node, nodedesc, sizeof(nodedesc));
|
|
|
|
|
|
|
|
|
|
switch (code)
|
|
|
|
|
{
|
|
|
|
|
case DISCARDING_UNEXPECTED:
|
|
|
|
|
/* Force error if in a bad form, or Issue #166 - repeated <main> element. */
|
|
|
|
|
/* Can we use `rpt` here? No; `element` has a value in every case. */
|
|
|
|
|
return TY_(tidyMessageCreateWithNode)(doc, node, code, doc->badForm ? TidyError : TidyWarning, nodedesc );
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*********************************************************************
|
|
|
|
|
* High Level Message Writing Functions
|
2017-02-13 19:29:47 +00:00
|
|
|
* When adding new reports to LibTidy, preference should be given
|
2017-09-02 20:47:14 +00:00
|
|
|
* to one of the existing, general pupose message writing functions
|
|
|
|
|
* above, if possible, otherwise try to use one of these, or as a
|
|
|
|
|
* last resort add a new one in this section.
|
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
|
|
|
2017-09-08 01:06:44 +00:00
|
|
|
/* This function performs the heavy lifting for TY_(Report)(). Critically we
|
|
|
|
|
** can accept the va_list needed for recursion.
|
|
|
|
|
*/
|
2017-09-02 20:47:14 +00:00
|
|
|
static void vReport(TidyDocImpl* doc, Node *element, Node *node, uint code, va_list args)
|
|
|
|
|
{
|
|
|
|
|
int i = 0;
|
|
|
|
|
va_list args_copy;
|
|
|
|
|
|
|
|
|
|
while ( dispatchTable[i].code != 0 )
|
|
|
|
|
{
|
|
|
|
|
if ( dispatchTable[i].code == code )
|
|
|
|
|
{
|
|
|
|
|
TidyMessageImpl *message;
|
|
|
|
|
messageFormatter *handler = dispatchTable[i].handler;
|
|
|
|
|
TidyReportLevel level = dispatchTable[i].level;
|
|
|
|
|
|
|
|
|
|
va_copy(args_copy, args);
|
|
|
|
|
message = handler( doc, element, node, code, level, args_copy );
|
|
|
|
|
va_end(args_copy);
|
|
|
|
|
|
|
|
|
|
messageOut( message );
|
|
|
|
|
|
|
|
|
|
if ( dispatchTable[i].next )
|
|
|
|
|
{
|
2017-09-08 01:06:44 +00:00
|
|
|
va_copy(args_copy, args);
|
|
|
|
|
vReport(doc, element, node, dispatchTable[i].next, args_copy);
|
|
|
|
|
va_end(args_copy);
|
2017-09-02 20:47:14 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
i++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* This single Report output function uses the correct formatter with all
|
|
|
|
|
** possible, relevant data that can be reported. The only real drawbacks are
|
|
|
|
|
** having to pass NULL when some of the values aren't used, and the lack of
|
|
|
|
|
** type safety by using the variable arguments. To counter this some convenience
|
2017-09-07 01:25:19 +00:00
|
|
|
** report output functions exist, too. Any new reports you wish to create must
|
|
|
|
|
** be able to use this function signature, although convenience functions should
|
|
|
|
|
** be added to abstract the full fuction signature and to preserve type safety.
|
2017-09-02 20:47:14 +00:00
|
|
|
*/
|
|
|
|
|
void TY_(Report)(TidyDocImpl* doc, Node *element, Node *node, uint code, ...)
|
|
|
|
|
{
|
|
|
|
|
va_list args;
|
|
|
|
|
va_start(args, code);
|
|
|
|
|
vReport(doc, element, node, code, args);
|
|
|
|
|
va_end(args);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*********************************************************************
|
|
|
|
|
* Convenience Reporting Functions
|
|
|
|
|
* Functions that don't require the full signature of TY_(Report),
|
2017-09-07 01:25:19 +00:00
|
|
|
* and help protect type safety by avoiding variable arguments in the
|
|
|
|
|
* rest of Tidy's code.
|
2017-09-02 20:47:14 +00:00
|
|
|
*********************************************************************/
|
|
|
|
|
|
2017-09-04 21:35:57 +00:00
|
|
|
void TY_(ReportAccessError)( TidyDocImpl* doc, Node* node, uint code )
|
|
|
|
|
{
|
|
|
|
|
TY_(Report)( doc, NULL, node, code );
|
|
|
|
|
}
|
|
|
|
|
|
2017-09-02 20:47:14 +00:00
|
|
|
|
2017-09-02 21:29:56 +00:00
|
|
|
void TY_(ReportAttrError)(TidyDocImpl* doc, Node *node, AttVal *av, uint code)
|
|
|
|
|
{
|
2017-09-04 19:50:45 +00:00
|
|
|
TY_(Report)( doc, NULL, node, code, av );
|
2017-09-02 21:29:56 +00:00
|
|
|
}
|
|
|
|
|
|
2017-09-02 22:00:46 +00:00
|
|
|
|
|
|
|
|
void TY_(ReportBadArgument)( TidyDocImpl* doc, ctmbstr option )
|
|
|
|
|
{
|
|
|
|
|
assert( option != NULL );
|
2017-09-04 19:50:45 +00:00
|
|
|
TY_(Report)( doc, NULL, NULL, STRING_MISSING_MALFORMED, option );
|
2017-09-02 22:00:46 +00:00
|
|
|
}
|
2017-09-02 20:47:14 +00:00
|
|
|
|
|
|
|
|
|
2017-09-04 19:28:08 +00:00
|
|
|
void TY_(ReportEntityError)( TidyDocImpl* doc, uint code, ctmbstr entity, int ARG_UNUSED(c) )
|
|
|
|
|
{
|
|
|
|
|
/* Note that the report formatter currently doesn't use argument c */
|
|
|
|
|
TY_(Report)( doc, NULL, NULL, code, entity, c );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-09-04 15:24:48 +00:00
|
|
|
void TY_(ReportFileError)( TidyDocImpl* doc, ctmbstr file, uint code )
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
2017-09-04 19:50:45 +00:00
|
|
|
TY_(Report)( doc, NULL, NULL, code, file );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void TY_(ReportEncodingError)(TidyDocImpl* doc, uint code, uint c, Bool discarded)
|
|
|
|
|
{
|
|
|
|
|
TY_(Report)( doc, NULL, NULL, code, c, discarded );
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
2017-09-04 20:12:01 +00:00
|
|
|
void TY_(ReportEncodingWarning)(TidyDocImpl* doc, uint code, uint encoding)
|
|
|
|
|
{
|
|
|
|
|
/* va_list in formatter expects trailing `no` argument */
|
|
|
|
|
TY_(Report)( doc, NULL, NULL, code, encoding, no );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void TY_(ReportMissingAttr)( TidyDocImpl* doc, Node* node, ctmbstr name )
|
|
|
|
|
{
|
|
|
|
|
TY_(Report)( doc, NULL, node, MISSING_ATTRIBUTE, name );
|
|
|
|
|
}
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
|
2017-09-04 20:38:07 +00:00
|
|
|
void TY_(ReportSurrogateError)(TidyDocImpl* doc, uint code, uint c1, uint c2)
|
|
|
|
|
{
|
|
|
|
|
TY_(Report)( doc, NULL, NULL, code, c1,c2 );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void TY_(ReportUnknownOption)( TidyDocImpl* doc, ctmbstr option )
|
|
|
|
|
{
|
|
|
|
|
/* lexer is not defined when this is called */
|
|
|
|
|
TY_(Report)( doc, NULL, NULL, STRING_UNKNOWN_OPTION, option );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
/*********************************************************************
|
2017-09-08 01:06:44 +00:00
|
|
|
* Dialogue Output Functions
|
|
|
|
|
* As for issuing reports, Tidy manages all dialogue output from a
|
|
|
|
|
* single source in order to manage message categories in a simple
|
|
|
|
|
* an consistent manner.
|
2017-02-13 19:29:47 +00:00
|
|
|
*********************************************************************/
|
|
|
|
|
|
2016-01-15 04:06:15 +00:00
|
|
|
|
2017-09-08 01:06:44 +00:00
|
|
|
/* This structure ties together for each dialogue Code the default
|
|
|
|
|
** TidyReportLevel. This it makes it simple to output new dialogue
|
|
|
|
|
** messages, or to change report level by modifying this array.
|
|
|
|
|
*/
|
|
|
|
|
static struct _dialogueDispatchTable {
|
|
|
|
|
uint code; /**< The message code. */
|
|
|
|
|
TidyReportLevel level; /**< The default TidyReportLevel of the message. */
|
|
|
|
|
} dialogueDispatchTable[] = {
|
2017-09-29 15:25:17 +00:00
|
|
|
{ STRING_HELLO_ACCESS, TidyDialogueInfo }, /* AccessibilityChecks() */
|
|
|
|
|
{ TEXT_GENERAL_INFO, TidyDialogueInfo }, /* tidyGeneralInfo() */
|
|
|
|
|
{ TEXT_GENERAL_INFO_PLEA, TidyDialogueInfo }, /* tidyGeneralInfo() */
|
2017-09-08 01:06:44 +00:00
|
|
|
|
2017-09-29 15:25:17 +00:00
|
|
|
{ STRING_NEEDS_INTERVENTION, TidyDialogueSummary }, /* tidyDocRunDiagnostics() */
|
|
|
|
|
{ STRING_ERROR_COUNT, TidyDialogueSummary }, /* ReportNumWarnings() */
|
|
|
|
|
{ STRING_NO_ERRORS, TidyDialogueSummary }, /* ReportNumWarnings() */
|
|
|
|
|
{ STRING_NOT_ALL_SHOWN, TidyDialogueSummary }, /* ReportNumWarnings() */
|
2017-09-08 01:06:44 +00:00
|
|
|
|
2017-09-29 15:25:17 +00:00
|
|
|
{ FOOTNOTE_TRIM_EMPTY_ELEMENT, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_ACCESS_ADVICE1, TidyDialogueFootnote }, /* errorSummary() */
|
|
|
|
|
{ TEXT_ACCESS_ADVICE2, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_BAD_FORM, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_BAD_MAIN, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_HTML_T_ALGORITHM, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_INVALID_URI, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_INVALID_UTF8, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_INVALID_UTF16, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_M_IMAGE_ALT, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_M_IMAGE_MAP, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_M_LINK_ALT, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_M_SUMMARY, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_SGML_CHARS, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_USING_BODY, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_USING_FONT, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_USING_FRAMES, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_USING_LAYER, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_USING_NOBR, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_USING_SPACER, TidyDialogueFootnote },
|
|
|
|
|
{ TEXT_VENDOR_CHARS, TidyDialogueFootnote },
|
|
|
|
|
|
|
|
|
|
{ 0, 0 }
|
2017-09-08 01:06:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* This message formatter for dialogue messages should be capable of formatting
|
|
|
|
|
** every message, because they're not all the complex and there aren't that
|
|
|
|
|
** many.
|
|
|
|
|
*/
|
|
|
|
|
TidyMessageImpl *formatDialogue( TidyDocImpl* doc, uint code, TidyReportLevel level, va_list args )
|
|
|
|
|
{
|
|
|
|
|
switch (code)
|
|
|
|
|
{
|
|
|
|
|
case TEXT_SGML_CHARS:
|
|
|
|
|
case TEXT_VENDOR_CHARS:
|
|
|
|
|
{
|
|
|
|
|
ctmbstr str = va_arg(args, ctmbstr);
|
|
|
|
|
return TY_(tidyMessageCreate)( doc, code, level, str );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case STRING_ERROR_COUNT:
|
|
|
|
|
case STRING_NOT_ALL_SHOWN:
|
|
|
|
|
return TY_(tidyMessageCreate)( doc, code, level,
|
|
|
|
|
doc->warnings, tidyLocalizedStringN( STRING_ERROR_COUNT_WARNING, doc->warnings ),
|
|
|
|
|
doc->errors, tidyLocalizedStringN( STRING_ERROR_COUNT_ERROR, doc->errors ) );
|
|
|
|
|
|
2017-09-29 15:25:17 +00:00
|
|
|
case FOOTNOTE_TRIM_EMPTY_ELEMENT:
|
2017-09-08 01:06:44 +00:00
|
|
|
case STRING_HELLO_ACCESS:
|
|
|
|
|
case STRING_NEEDS_INTERVENTION:
|
|
|
|
|
case STRING_NO_ERRORS:
|
|
|
|
|
case TEXT_ACCESS_ADVICE1:
|
|
|
|
|
case TEXT_ACCESS_ADVICE2:
|
|
|
|
|
case TEXT_BAD_FORM:
|
|
|
|
|
case TEXT_BAD_MAIN:
|
|
|
|
|
case TEXT_GENERAL_INFO:
|
|
|
|
|
case TEXT_GENERAL_INFO_PLEA:
|
|
|
|
|
case TEXT_HTML_T_ALGORITHM:
|
|
|
|
|
case TEXT_INVALID_URI:
|
|
|
|
|
case TEXT_INVALID_UTF8:
|
|
|
|
|
case TEXT_INVALID_UTF16:
|
|
|
|
|
case TEXT_M_IMAGE_ALT:
|
|
|
|
|
case TEXT_M_IMAGE_MAP:
|
|
|
|
|
case TEXT_M_LINK_ALT:
|
|
|
|
|
case TEXT_M_SUMMARY:
|
|
|
|
|
case TEXT_USING_BODY:
|
|
|
|
|
case TEXT_USING_FONT:
|
|
|
|
|
case TEXT_USING_FRAMES:
|
|
|
|
|
case TEXT_USING_LAYER:
|
|
|
|
|
case TEXT_USING_NOBR:
|
|
|
|
|
case TEXT_USING_SPACER:
|
|
|
|
|
default:
|
|
|
|
|
return TY_(tidyMessageCreate)( doc, code, level );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* This single Dialogue output function determines the correct message level
|
|
|
|
|
** and formats the message with the appropriate formatter, and then outputs it.
|
|
|
|
|
** This one dialogue function should be sufficient for every use case.
|
|
|
|
|
*/
|
|
|
|
|
void TY_(Dialogue)(TidyDocImpl* doc, uint code, ...)
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
{
|
2017-09-08 01:06:44 +00:00
|
|
|
int i = 0;
|
|
|
|
|
va_list args;
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
|
2017-09-08 01:06:44 +00:00
|
|
|
while ( dialogueDispatchTable[i].code != 0 )
|
|
|
|
|
{
|
|
|
|
|
if ( dialogueDispatchTable[i].code == code )
|
|
|
|
|
{
|
2017-09-22 23:27:47 +00:00
|
|
|
TidyMessageImpl *message;
|
2017-09-08 01:06:44 +00:00
|
|
|
TidyReportLevel level = dialogueDispatchTable[i].level;
|
|
|
|
|
va_start(args, code);
|
2017-09-22 21:27:49 +00:00
|
|
|
message = formatDialogue( doc, code, level, args );
|
2017-09-08 01:06:44 +00:00
|
|
|
va_end(args);
|
|
|
|
|
messageOut( message );
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
i++;
|
|
|
|
|
}
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-09-08 01:06:44 +00:00
|
|
|
/*********************************************************************
|
|
|
|
|
* Output Dialogue Information
|
|
|
|
|
* In addition to reports that are added to the table, Tidy emits
|
|
|
|
|
* various dialogue type information. Most of these are specific to
|
|
|
|
|
* exact circumstances, although `TY_(Dialogue)` should be used
|
|
|
|
|
* instead of adding a new function, if possible.
|
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Outputs the footnotes and other dialogue information after document cleanup
|
|
|
|
|
** is complete. LibTidy users might consider capturing these individually in
|
|
|
|
|
** the message callback rather than capturing this entire buffer.
|
|
|
|
|
** Called by tidyErrorSummary(), in console.
|
|
|
|
|
** @todo: This name is a bit misleading and should probably be renamed to
|
|
|
|
|
** indicate its focus on printing footnotes.
|
|
|
|
|
*/
|
2016-01-15 04:06:15 +00:00
|
|
|
void TY_(ErrorSummary)( TidyDocImpl* doc )
|
|
|
|
|
{
|
|
|
|
|
ctmbstr encnam = tidyLocalizedString(STRING_SPECIFIED);
|
|
|
|
|
int charenc = cfg( doc, TidyCharEncoding );
|
|
|
|
|
if ( charenc == WIN1252 )
|
|
|
|
|
encnam = "Windows-1252";
|
|
|
|
|
else if ( charenc == MACROMAN )
|
|
|
|
|
encnam = "MacRoman";
|
|
|
|
|
else if ( charenc == IBM858 )
|
|
|
|
|
encnam = "ibm858";
|
|
|
|
|
else if ( charenc == LATIN0 )
|
|
|
|
|
encnam = "latin0";
|
|
|
|
|
|
|
|
|
|
/* adjust badAccess to that it is 0 if frames are ok */
|
|
|
|
|
if ( doc->badAccess & (BA_USING_FRAMES | BA_USING_NOFRAMES) )
|
|
|
|
|
{
|
|
|
|
|
if (!((doc->badAccess & BA_USING_FRAMES) && !(doc->badAccess & BA_USING_NOFRAMES)))
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
{
|
2016-01-15 04:06:15 +00:00
|
|
|
doc->badAccess &= ~(BA_USING_FRAMES | BA_USING_NOFRAMES);
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
}
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (doc->badChars)
|
|
|
|
|
{
|
|
|
|
|
if (doc->badChars & BC_VENDOR_SPECIFIC_CHARS)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_VENDOR_CHARS, encnam );
|
|
|
|
|
|
2016-01-15 04:06:15 +00:00
|
|
|
if ((doc->badChars & BC_INVALID_SGML_CHARS) || (doc->badChars & BC_INVALID_NCR))
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_SGML_CHARS, encnam );
|
|
|
|
|
|
2016-01-15 04:06:15 +00:00
|
|
|
if (doc->badChars & BC_INVALID_UTF8)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_INVALID_UTF8 );
|
2016-01-15 04:06:15 +00:00
|
|
|
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
if (doc->badChars & BC_INVALID_UTF16)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_INVALID_UTF16 );
|
2016-01-15 04:06:15 +00:00
|
|
|
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
if (doc->badChars & BC_INVALID_URI)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_INVALID_URI );
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
2017-09-08 01:06:44 +00:00
|
|
|
|
|
|
|
|
if (doc->badForm)
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
2017-09-08 01:06:44 +00:00
|
|
|
if (doc->badForm & flg_BadForm) /* Issue #166 - changed to BIT flag to support other errors */
|
|
|
|
|
TY_(Dialogue)( doc, TEXT_BAD_FORM );
|
2016-01-15 04:06:15 +00:00
|
|
|
|
2017-09-08 01:06:44 +00:00
|
|
|
if (doc->badForm & flg_BadMain) /* Issue #166 - repeated <main> element */
|
|
|
|
|
TY_(Dialogue)( doc, TEXT_BAD_MAIN );
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
|
2016-01-15 04:06:15 +00:00
|
|
|
if (doc->badAccess)
|
|
|
|
|
{
|
|
|
|
|
/* Tidy "classic" accessibility tests */
|
|
|
|
|
if ( cfg(doc, TidyAccessibilityCheckLevel) == 0 )
|
|
|
|
|
{
|
|
|
|
|
if (doc->badAccess & BA_MISSING_SUMMARY)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_M_SUMMARY );
|
2016-01-15 04:06:15 +00:00
|
|
|
|
|
|
|
|
if (doc->badAccess & BA_MISSING_IMAGE_ALT)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_M_IMAGE_ALT );
|
2016-01-15 04:06:15 +00:00
|
|
|
|
|
|
|
|
if (doc->badAccess & BA_MISSING_IMAGE_MAP)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_M_IMAGE_MAP );
|
2016-01-15 04:06:15 +00:00
|
|
|
|
|
|
|
|
if (doc->badAccess & BA_MISSING_LINK_ALT)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_M_LINK_ALT );
|
2016-01-15 04:06:15 +00:00
|
|
|
|
|
|
|
|
if ((doc->badAccess & BA_USING_FRAMES) && !(doc->badAccess & BA_USING_NOFRAMES))
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_USING_FRAMES );
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( cfg(doc, TidyAccessibilityCheckLevel) > 0 )
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_ACCESS_ADVICE2 );
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
else
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_ACCESS_ADVICE1 );
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (doc->badLayout)
|
|
|
|
|
{
|
|
|
|
|
if (doc->badLayout & USING_LAYER)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_USING_LAYER );
|
2016-01-15 04:06:15 +00:00
|
|
|
|
|
|
|
|
if (doc->badLayout & USING_SPACER)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_USING_SPACER );
|
2016-01-15 04:06:15 +00:00
|
|
|
|
|
|
|
|
if (doc->badLayout & USING_FONT)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_USING_FONT );
|
2016-01-15 04:06:15 +00:00
|
|
|
|
|
|
|
|
if (doc->badLayout & USING_NOBR)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_USING_NOBR );
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
|
2016-01-15 04:06:15 +00:00
|
|
|
if (doc->badLayout & USING_BODY)
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, TEXT_USING_BODY );
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
2017-09-29 15:25:17 +00:00
|
|
|
|
|
|
|
|
if (doc->footnotes)
|
|
|
|
|
{
|
|
|
|
|
if (doc->footnotes & FN_TRIM_EMPTY_ELEMENT)
|
|
|
|
|
TY_(Dialogue)( doc, FOOTNOTE_TRIM_EMPTY_ELEMENT );
|
|
|
|
|
}
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-09-08 01:06:44 +00:00
|
|
|
/* Outputs document HTML version and version-related information.
|
|
|
|
|
** Called by tidyRunDiagnostics(), from console.
|
|
|
|
|
** Called by tidyDocReportDoctype(), currently unused.
|
|
|
|
|
*/
|
2017-09-04 20:49:49 +00:00
|
|
|
void TY_(ReportMarkupVersion)( TidyDocImpl* doc )
|
|
|
|
|
{
|
|
|
|
|
if ( doc->givenDoctype )
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Report)( doc, NULL, NULL, STRING_DOCTYPE_GIVEN, doc->givenDoctype );
|
2017-09-04 20:49:49 +00:00
|
|
|
|
|
|
|
|
if ( ! cfgBool(doc, TidyXmlTags) )
|
|
|
|
|
{
|
|
|
|
|
Bool isXhtml = doc->lexer->isvoyager;
|
2017-09-08 01:06:44 +00:00
|
|
|
uint apparentVers = TY_(ApparentVersion)( doc );
|
|
|
|
|
ctmbstr vers = TY_(HTMLVersionNameFromCode)( apparentVers, isXhtml );
|
2017-09-04 20:49:49 +00:00
|
|
|
|
|
|
|
|
if ( !vers )
|
|
|
|
|
vers = tidyLocalizedString(STRING_HTML_PROPRIETARY);
|
|
|
|
|
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Report)( doc, NULL, NULL, STRING_CONTENT_LOOKS, vers );
|
2017-09-04 20:49:49 +00:00
|
|
|
|
|
|
|
|
/* Warn about missing sytem identifier (SI) in emitted doctype */
|
|
|
|
|
if ( TY_(WarnMissingSIInEmittedDocType)( doc ) )
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Report)( doc, NULL, NULL, STRING_NO_SYSID );
|
2017-09-04 20:49:49 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-09-08 01:06:44 +00:00
|
|
|
/* Reports the number of warnings and errors found in the document.
|
|
|
|
|
** Called by tidyRunDiagnostics(), from console.
|
|
|
|
|
*/
|
2017-02-13 19:29:47 +00:00
|
|
|
void TY_(ReportNumWarnings)( TidyDocImpl* doc )
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
2017-02-13 19:29:47 +00:00
|
|
|
if ( doc->warnings > 0 || doc->errors > 0 )
|
|
|
|
|
{
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
if ( doc->errors > cfg(doc, TidyShowErrors) || !cfgBool(doc, TidyShowWarnings) )
|
|
|
|
|
{
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, STRING_NOT_ALL_SHOWN );
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
}
|
2017-02-13 19:29:47 +00:00
|
|
|
else
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
{
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, STRING_ERROR_COUNT );
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
}
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
}
|
|
|
|
|
else
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
{
|
2017-09-08 01:06:44 +00:00
|
|
|
TY_(Dialogue)( doc, STRING_NO_ERRORS );
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
}
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
|
2017-10-08 14:47:03 +00:00
|
|
|
/*********************************************************************
|
2017-10-10 12:21:14 +00:00
|
|
|
* Message Muting
|
2017-10-08 14:47:03 +00:00
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
|
|
|
2017-10-10 12:21:14 +00:00
|
|
|
void TY_(FreeMutedMessageList)( TidyDocImpl* doc )
|
2017-10-08 14:47:03 +00:00
|
|
|
{
|
2017-10-10 12:21:14 +00:00
|
|
|
TidyMutedMessages *list = &(doc->muted);
|
2017-10-08 14:47:03 +00:00
|
|
|
|
|
|
|
|
if ( list->list )
|
|
|
|
|
TidyFree( doc->allocator, list->list );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-10-10 12:21:14 +00:00
|
|
|
void TY_(DefineMutedMessage)(TidyDocImpl* doc, const TidyOptionImpl* opt, ctmbstr name)
|
2017-10-08 14:47:03 +00:00
|
|
|
{
|
|
|
|
|
enum { capacity = 10 };
|
2017-10-10 12:21:14 +00:00
|
|
|
TidyMutedMessages *list = &(doc->muted);
|
2017-10-08 14:47:03 +00:00
|
|
|
tidyStrings message = TY_(tidyErrorCodeFromKey)( name );
|
|
|
|
|
|
|
|
|
|
if ( message <= REPORT_MESSAGE_FIRST || message >= REPORT_MESSAGE_LAST)
|
2017-10-08 15:19:00 +00:00
|
|
|
{
|
2017-10-08 14:47:03 +00:00
|
|
|
TY_(Report)( doc, NULL, NULL, STRING_ARGUMENT_BAD, opt->name, name );
|
2017-10-08 15:19:00 +00:00
|
|
|
return;
|
|
|
|
|
}
|
2017-10-08 14:47:03 +00:00
|
|
|
|
|
|
|
|
if ( !list->list )
|
|
|
|
|
{
|
|
|
|
|
list->list = TidyAlloc(doc->allocator, sizeof(tidyStrings) * capacity );
|
|
|
|
|
list->list[0] = 0;
|
|
|
|
|
list->capacity = capacity;
|
|
|
|
|
list->count = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( list->count >= list->capacity )
|
|
|
|
|
{
|
|
|
|
|
list->capacity = list->capacity * 2;
|
|
|
|
|
list->list = realloc( list->list, sizeof(tidyStrings) * list->capacity + 1 );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
list->list[list->count] = message;
|
|
|
|
|
list->count++;
|
|
|
|
|
list->list[list->count] = 0;
|
|
|
|
|
|
2017-10-10 12:21:14 +00:00
|
|
|
/* Must come *after* adding to the list, in case it's muted, too. */
|
|
|
|
|
TY_(Report)( doc, NULL, NULL, STRING_MUTING_TYPE, name );
|
2017-10-08 14:47:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-11-19 15:21:46 +00:00
|
|
|
TidyIterator TY_(getMutedMessageList)( TidyDocImpl* doc )
|
|
|
|
|
{
|
|
|
|
|
TidyMutedMessages *list = &(doc->muted);
|
|
|
|
|
size_t result = list->count > 0 ? 1 : 0;
|
|
|
|
|
|
|
|
|
|
return (TidyIterator) result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ctmbstr TY_(getNextMutedMessage)( TidyDocImpl* doc, TidyIterator* iter )
|
|
|
|
|
{
|
|
|
|
|
TidyMutedMessages *list = &(doc->muted);
|
|
|
|
|
size_t index;
|
|
|
|
|
ctmbstr result = NULL;
|
|
|
|
|
assert( iter != NULL );
|
|
|
|
|
index = (size_t)*iter;
|
|
|
|
|
|
2017-11-19 16:02:13 +00:00
|
|
|
if ( index > 0 && index <= list->count )
|
2017-11-19 15:21:46 +00:00
|
|
|
{
|
|
|
|
|
result = TY_(tidyErrorCodeAsKey)(list->list[index-1]);
|
|
|
|
|
index++;
|
|
|
|
|
}
|
|
|
|
|
*iter = (TidyIterator) ( index <= list->count ? index : (size_t)0 );
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
/*********************************************************************
|
|
|
|
|
* Key Discovery
|
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*********************************************************************
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
* LibTidy users may want to to enable their own localization lookup
|
|
|
|
|
* lookup methods. Because Tidy's errors codes are enums, the actual
|
|
|
|
|
* values can change over time. This table will the LibTidy users
|
|
|
|
|
* always have a static value available for use.
|
2017-02-13 19:29:47 +00:00
|
|
|
*
|
|
|
|
|
* For macro documentation, refer to the comments in `tidyenum.h`.
|
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
Continue the documentation effort!
- 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.
2017-03-21 01:07:53 +00:00
|
|
|
typedef struct tidyStringsKeyItem {
|
2017-02-13 19:29:47 +00:00
|
|
|
ctmbstr key;
|
|
|
|
|
int value;
|
Continue the documentation effort!
- 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.
2017-03-21 01:07:53 +00:00
|
|
|
} tidyStringsKeyItem;
|
|
|
|
|
|
|
|
|
|
static const tidyStringsKeyItem tidyStringsKeys[] = {
|
|
|
|
|
FOREACH_TIDYCONFIGCATEGORY(MAKE_STRUCT)
|
|
|
|
|
FOREACH_MSG_MISC(MAKE_STRUCT)
|
2017-09-08 01:06:44 +00:00
|
|
|
FOREACH_FOOTNOTE_MSG(MAKE_STRUCT)
|
Continue the documentation effort!
- 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.
2017-03-21 01:07:53 +00:00
|
|
|
FOREACH_DIALOG_MSG(MAKE_STRUCT)
|
|
|
|
|
FOREACH_REPORT_MSG(MAKE_STRUCT)
|
|
|
|
|
FOREACH_ACCESS_MSG(MAKE_STRUCT)
|
|
|
|
|
#if SUPPORT_CONSOLE_APP
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
FOREACH_MSG_CONSOLE(MAKE_STRUCT)
|
Continue the documentation effort!
- 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.
2017-03-21 01:07:53 +00:00
|
|
|
#endif
|
2017-10-03 18:00:40 +00:00
|
|
|
{ "TIDYSTRINGS_FIRST", TIDYSTRINGS_FIRST },
|
Continue the documentation effort!
- 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.
2017-03-21 01:07:53 +00:00
|
|
|
{ "TIDYSTRINGS_LAST", TIDYSTRINGS_LAST },
|
|
|
|
|
{ NULL, 0 },
|
2017-02-13 19:29:47 +00:00
|
|
|
};
|
2016-01-15 04:06:15 +00:00
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Given an error code, return the string associated with it.
|
|
|
|
|
*/
|
|
|
|
|
ctmbstr TY_(tidyErrorCodeAsKey)(uint code)
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
2017-02-13 19:29:47 +00:00
|
|
|
uint i = 0;
|
Continue the documentation effort!
- 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.
2017-03-21 01:07:53 +00:00
|
|
|
while (tidyStringsKeys[i].key) {
|
|
|
|
|
if ( tidyStringsKeys[i].value == code )
|
|
|
|
|
return tidyStringsKeys[i].key;
|
2017-02-13 19:29:47 +00:00
|
|
|
i++;
|
|
|
|
|
}
|
|
|
|
|
return "UNDEFINED";
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-03-16 20:46:01 +00:00
|
|
|
/**
|
|
|
|
|
* Given an error code string, return its uint.
|
|
|
|
|
*/
|
|
|
|
|
uint TY_(tidyErrorCodeFromKey)(ctmbstr code)
|
|
|
|
|
{
|
|
|
|
|
uint i = 0;
|
Continue the documentation effort!
- 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.
2017-03-21 01:07:53 +00:00
|
|
|
while (tidyStringsKeys[i].key) {
|
|
|
|
|
if ( strcmp(tidyStringsKeys[i].key, code) == 0 )
|
|
|
|
|
return tidyStringsKeys[i].value;
|
2017-03-16 20:46:01 +00:00
|
|
|
i++;
|
|
|
|
|
}
|
|
|
|
|
return UINT_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
/**
|
|
|
|
|
* Determines the number of error codes used by Tidy.
|
|
|
|
|
*/
|
|
|
|
|
static const uint tidyErrorCodeListSize()
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
2017-02-13 19:29:47 +00:00
|
|
|
static uint array_size = 0;
|
|
|
|
|
|
|
|
|
|
if ( array_size == 0 )
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
Continue the documentation effort!
- 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.
2017-03-21 01:07:53 +00:00
|
|
|
while ( tidyStringsKeys[array_size].key ) {
|
2017-02-13 19:29:47 +00:00
|
|
|
array_size++;
|
|
|
|
|
}
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
2017-02-13 19:29:47 +00:00
|
|
|
|
|
|
|
|
return array_size;
|
|
|
|
|
}
|
2016-01-15 04:06:15 +00:00
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
/**
|
|
|
|
|
* Initializes the TidyIterator to point to the first item
|
Massive Revamp of the Messaging System
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.
2017-03-13 17:28:57 +00:00
|
|
|
* in Tidy's list of error codes. Individual items must be
|
|
|
|
|
* retrieved with getNextErrorCode();
|
2017-02-13 19:29:47 +00:00
|
|
|
*/
|
|
|
|
|
TidyIterator TY_(getErrorCodeList)()
|
|
|
|
|
{
|
|
|
|
|
return (TidyIterator)(size_t)1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Returns the next error code.
|
|
|
|
|
*/
|
|
|
|
|
uint TY_(getNextErrorCode)( TidyIterator* iter )
|
|
|
|
|
{
|
Continue the documentation effort!
- 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.
2017-03-21 01:07:53 +00:00
|
|
|
const tidyStringsKeyItem *item = NULL;
|
2017-02-13 19:29:47 +00:00
|
|
|
size_t itemIndex;
|
|
|
|
|
assert( iter != NULL );
|
|
|
|
|
|
|
|
|
|
itemIndex = (size_t)*iter;
|
|
|
|
|
|
|
|
|
|
if ( itemIndex > 0 && itemIndex <= tidyErrorCodeListSize() )
|
2016-01-15 04:06:15 +00:00
|
|
|
{
|
Continue the documentation effort!
- 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.
2017-03-21 01:07:53 +00:00
|
|
|
item = &tidyStringsKeys[itemIndex - 1];
|
2017-02-13 19:29:47 +00:00
|
|
|
itemIndex++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*iter = (TidyIterator)( itemIndex <= tidyErrorCodeListSize() ? itemIndex : (size_t)0 );
|
|
|
|
|
return item->value;
|
|
|
|
|
}
|
2016-01-15 04:06:15 +00:00
|
|
|
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
/*********************************************************************
|
|
|
|
|
* Documentation of configuration options
|
|
|
|
|
*
|
|
|
|
|
* Although most of the strings now come from the language module,
|
|
|
|
|
* generating the documentation by the console application requires a
|
|
|
|
|
* series of cross-references that are generated in this messaging
|
|
|
|
|
* module.
|
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#if SUPPORT_CONSOLE_APP
|
|
|
|
|
/* Cross-references definitions.
|
|
|
|
|
* Note that each list must be terminated with `TidyUnknownOption`.
|
|
|
|
|
*/
|
|
|
|
|
static const TidyOptionId TidyAsciiCharsLinks[] = { TidyMakeClean, TidyUnknownOption };
|
2017-03-13 17:45:32 +00:00
|
|
|
static const TidyOptionId TidyBlockTagsLinks[] = { TidyEmptyTags, TidyInlineTags, TidyPreTags, TidyUseCustomTags, TidyUnknownOption };
|
2017-02-13 19:29:47 +00:00
|
|
|
static const TidyOptionId TidyCharEncodingLinks[] = { TidyInCharEncoding, TidyOutCharEncoding, TidyUnknownOption };
|
|
|
|
|
static const TidyOptionId TidyDuplicateAttrsLinks[] = { TidyJoinClasses, TidyJoinStyles, TidyUnknownOption };
|
2017-03-13 17:45:32 +00:00
|
|
|
static const TidyOptionId TidyEmptyTagsLinks[] = { TidyBlockTags, TidyInlineTags, TidyPreTags, TidyUseCustomTags, TidyUnknownOption };
|
2017-02-13 19:29:47 +00:00
|
|
|
static const TidyOptionId TidyErrFileLinks[] = { TidyOutFile, TidyUnknownOption };
|
|
|
|
|
static const TidyOptionId TidyInCharEncodingLinks[] = { TidyCharEncoding, TidyUnknownOption };
|
|
|
|
|
static const TidyOptionId TidyIndentContentLinks[] = { TidyIndentSpaces, TidyUnknownOption };
|
|
|
|
|
static const TidyOptionId TidyIndentSpacesLinks[] = { TidyIndentContent, TidyUnknownOption };
|
2017-03-13 17:45:32 +00:00
|
|
|
static const TidyOptionId TidyInlineTagsLinks[] = { TidyBlockTags, TidyEmptyTags, TidyPreTags, TidyUseCustomTags, TidyUnknownOption };
|
2017-02-13 19:29:47 +00:00
|
|
|
static const TidyOptionId TidyMergeDivsLinks[] = { TidyMakeClean, TidyMergeSpans, TidyUnknownOption };
|
|
|
|
|
static const TidyOptionId TidyMergeSpansLinks[] = { TidyMakeClean, TidyMergeDivs, TidyUnknownOption };
|
2017-10-20 00:33:17 +00:00
|
|
|
static const TidyOptionId TidyMuteLinks[] = { TidyMuteShow, TidyUnknownOption };
|
|
|
|
|
static const TidyOptionId TidyMuteShowLinks[] = { TidyMuteReports, TidyUnknownOption };
|
2017-02-13 19:29:47 +00:00
|
|
|
static const TidyOptionId TidyNumEntitiesLinks[] = { TidyDoctype, TidyPreserveEntities, TidyUnknownOption };
|
|
|
|
|
static const TidyOptionId TidyOutCharEncodingLinks[] = { TidyCharEncoding, TidyUnknownOption };
|
|
|
|
|
static const TidyOptionId TidyOutFileLinks[] = { TidyErrFile, TidyUnknownOption };
|
2017-03-13 17:45:32 +00:00
|
|
|
static const TidyOptionId TidyPreTagsLinks[] = { TidyBlockTags, TidyEmptyTags, TidyInlineTags, TidyUseCustomTags, TidyUnknownOption };
|
2017-09-23 11:53:57 +00:00
|
|
|
static const TidyOptionId TidySortAttributesLinks[] = { TidyPriorityAttributes, TidyUnknownOption };
|
2017-03-13 17:45:32 +00:00
|
|
|
static const TidyOptionId TidyUseCustomTagsLinks[] = { TidyBlockTags, TidyEmptyTags, TidyInlineTags, TidyPreTags, TidyUnknownOption };
|
2017-02-13 19:29:47 +00:00
|
|
|
static const TidyOptionId TidyWrapAttValsLinks[] = { TidyWrapScriptlets, TidyLiteralAttribs, TidyUnknownOption };
|
|
|
|
|
static const TidyOptionId TidyWrapScriptletsLinks[] = { TidyWrapAttVals, TidyUnknownOption };
|
|
|
|
|
static const TidyOptionId TidyXmlDeclLinks[] = { TidyCharEncoding, TidyOutCharEncoding, TidyUnknownOption };
|
|
|
|
|
|
|
|
|
|
/* Cross-reference assignments.
|
|
|
|
|
* We can't build a complex array at compile time and we're not counting on
|
|
|
|
|
* any type of initialization, so this two-stage building process is required.
|
|
|
|
|
*/
|
|
|
|
|
static const TidyOptionDoc docs_xrefs[] =
|
|
|
|
|
{
|
|
|
|
|
{ TidyAsciiChars, TidyAsciiCharsLinks },
|
|
|
|
|
{ TidyBlockTags, TidyBlockTagsLinks },
|
|
|
|
|
{ TidyCharEncoding, TidyCharEncodingLinks },
|
|
|
|
|
{ TidyDuplicateAttrs, TidyDuplicateAttrsLinks },
|
|
|
|
|
{ TidyEmptyTags, TidyEmptyTagsLinks },
|
|
|
|
|
{ TidyErrFile, TidyErrFileLinks },
|
|
|
|
|
{ TidyInCharEncoding, TidyInCharEncodingLinks },
|
|
|
|
|
{ TidyIndentContent, TidyIndentContentLinks },
|
|
|
|
|
{ TidyIndentSpaces, TidyIndentSpacesLinks },
|
|
|
|
|
{ TidyInlineTags, TidyInlineTagsLinks },
|
|
|
|
|
{ TidyMergeDivs, TidyMergeDivsLinks },
|
|
|
|
|
{ TidyMergeSpans, TidyMergeSpansLinks },
|
2017-10-10 12:21:14 +00:00
|
|
|
{ TidyMuteShow, TidyMuteShowLinks },
|
2017-02-13 19:29:47 +00:00
|
|
|
{ TidyNumEntities, TidyNumEntitiesLinks },
|
|
|
|
|
{ TidyOutCharEncoding, TidyOutCharEncodingLinks },
|
|
|
|
|
{ TidyOutFile, TidyOutFileLinks },
|
|
|
|
|
{ TidyPreTags, TidyPreTagsLinks },
|
2017-09-23 11:53:57 +00:00
|
|
|
{ TidySortAttributes, TidySortAttributesLinks },
|
2017-10-10 12:21:14 +00:00
|
|
|
{ TidyMuteReports, TidyMuteLinks },
|
2017-03-13 17:45:32 +00:00
|
|
|
{ TidyUseCustomTags, TidyUseCustomTagsLinks },
|
2017-02-13 19:29:47 +00:00
|
|
|
{ TidyWrapAttVals, TidyWrapAttValsLinks },
|
|
|
|
|
{ TidyWrapScriptlets, TidyWrapScriptletsLinks },
|
|
|
|
|
{ TidyXmlDecl, TidyXmlDeclLinks },
|
|
|
|
|
{ N_TIDY_OPTIONS }
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Cross-reference retrieval. */
|
|
|
|
|
const TidyOptionDoc* TY_(OptGetDocDesc)( TidyOptionId optId )
|
|
|
|
|
{
|
|
|
|
|
uint i = 0;
|
|
|
|
|
|
|
|
|
|
while( docs_xrefs[i].opt != N_TIDY_OPTIONS )
|
|
|
|
|
{
|
|
|
|
|
if ( docs_xrefs[i].opt == optId )
|
|
|
|
|
return &docs_xrefs[i];
|
|
|
|
|
++i;
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
2017-02-13 19:29:47 +00:00
|
|
|
return NULL;
|
2016-01-15 04:06:15 +00:00
|
|
|
}
|
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
#endif /* SUPPORT_CONSOLE_APP */
|
|
|
|
|
|
|
|
|
|
|
2016-01-15 04:06:15 +00:00
|
|
|
/*
|
|
|
|
|
* local variables:
|
|
|
|
|
* mode: c
|
|
|
|
|
* indent-tabs-mode: nil
|
|
|
|
|
* c-basic-offset: 4
|
|
|
|
|
* eval: (c-set-offset 'substatement-open 0)
|
|
|
|
|
* end:
|
|
|
|
|
*/
|
