2011-11-17 02:44:16 +00:00
|
|
|
#ifndef __MESSAGE_H__
|
|
|
|
#define __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
|
|
|
/******************************************************************************
|
2017-09-19 19:07:52 +00:00
|
|
|
* @file
|
|
|
|
* Provides General Message Writing Routines
|
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
|
|
|
* This module handles LibTidy's high level output routines, as well as
|
|
|
|
* provides lookup functions and management for keys used for retrieval
|
|
|
|
* of these messages.
|
2017-02-13 19:29:47 +00:00
|
|
|
*
|
|
|
|
* LibTidy emits two general types of output:
|
|
|
|
*
|
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
|
|
|
* - Reports, which contain data relating to what Tidy discovered in your
|
|
|
|
* source file, and/or what Tidy did to your source file. In some cases
|
|
|
|
* general information about your source file is emitted as well. Reports
|
|
|
|
* are emitted in the current output buffer, but LibTidy users will probably
|
|
|
|
* prefer to hook into a callback in order to take advantage of the data
|
|
|
|
* that are available in a more flexible way.
|
2017-02-13 19:29:47 +00:00
|
|
|
*
|
2017-09-19 19:07:52 +00:00
|
|
|
* - Dialogue, consisting of footnotes related to your source file, and of
|
|
|
|
* general information that's not related to your source file in particular.
|
|
|
|
* This is also written to the current output buffer when appropriate, and
|
|
|
|
* available via callbacks.
|
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
|
|
|
* Report information typically takes the form of a warning, an error, info,
|
|
|
|
* etc., and the output routines keep track of the count of these.
|
2017-02-13 19:29:47 +00:00
|
|
|
*
|
|
|
|
* The preferred way of handling Tidy diagnostics output is either
|
|
|
|
* - define a new output sink, or
|
|
|
|
* - use a message filter callback routine.
|
2017-09-19 19:07:52 +00:00
|
|
|
*
|
|
|
|
* @author HTACG, et al (consult git log)
|
|
|
|
*
|
|
|
|
* @copyright
|
|
|
|
* Copyright (c) 1998-2017 World Wide Web Consortium (Massachusetts
|
|
|
|
* Institute of Technology, European Research Consortium for Informatics
|
|
|
|
* and Mathematics, Keio University) and HTACG.
|
|
|
|
* @par
|
|
|
|
* All Rights Reserved.
|
|
|
|
* @par
|
|
|
|
* See `tidy.h` for the complete license.
|
|
|
|
*
|
|
|
|
* @date Additional updates: consult git log
|
|
|
|
*
|
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
|
|
|
******************************************************************************/
|
2011-11-17 02:44:16 +00:00
|
|
|
|
|
|
|
#include "forward.h"
|
2017-10-08 14:47:03 +00:00
|
|
|
#include "config.h"
|
2017-02-13 19:29:47 +00:00
|
|
|
|
2017-09-19 19:07:52 +00:00
|
|
|
/** @addtogroup internal_api */
|
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
|
|
|
/** @{ */
|
|
|
|
|
2011-11-17 02:44:16 +00:00
|
|
|
|
2017-09-19 19:07:52 +00:00
|
|
|
/***************************************************************************//**
|
|
|
|
** @defgroup message_releaseinfo Tidy Release Information
|
|
|
|
**
|
|
|
|
** These functions return information about the current release version date
|
|
|
|
** and version number. Note that the latest release date or the highest
|
|
|
|
** version number alone do not guarantee the latest Tidy release, as we may
|
|
|
|
** backport important fixes to older releases of Tidy.
|
|
|
|
**
|
|
|
|
** @{
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the release date of this instance of HTML Tidy.
|
|
|
|
*/
|
2011-11-17 02:44:16 +00:00
|
|
|
ctmbstr TY_(ReleaseDate)(void);
|
2017-09-19 19:07:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the release version of this instance of HTML Tidy.
|
|
|
|
*/
|
2017-02-13 19:29:47 +00:00
|
|
|
ctmbstr TY_(tidyLibraryVersion)(void);
|
2011-11-17 02:44:16 +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
|
|
|
|
2017-09-19 19:07:52 +00:00
|
|
|
/** @} message_releaseinfo group */
|
|
|
|
|
|
|
|
|
|
|
|
/***************************************************************************//**
|
|
|
|
** @defgroup message_reporting Report and Dialogue Writing Functions
|
|
|
|
**
|
|
|
|
** These simple functions perform the vast majority of Tidy's output, and
|
|
|
|
** one these should be your first choice when adding your own output.
|
|
|
|
**
|
|
|
|
** A report is typically diagnostic output that is generated each time Tidy
|
|
|
|
** detects an issue in your document or makes a change. A dialogue is a piece
|
|
|
|
** of information such as a summary, a footnote, or other non-tabular data.
|
|
|
|
** Some of these functions emit multiple reports or dialogue in order to
|
|
|
|
** effect a summary.
|
|
|
|
**
|
|
|
|
** @{
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
/** @name General Report Writing
|
|
|
|
** If one of the convenience reporting functions does not fit your required
|
|
|
|
** message signature, then this designated reporting function will fit the
|
|
|
|
** bill. Be sure to see if a message formatter exists that can handle the
|
|
|
|
** variable arguments.
|
|
|
|
*/
|
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-19 19:07:52 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* The designated report writing function. When a proper formatter exists,
|
|
|
|
* this one function can hanle all report output.
|
|
|
|
*/
|
2017-09-02 20:47:14 +00:00
|
|
|
void TY_(Report)(TidyDocImpl* doc, Node *element, Node *node, uint code, ...);
|
2011-11-17 02:44:16 +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
|
|
|
|
|
|
|
/** @} */
|
2017-09-19 19:07:52 +00:00
|
|
|
/** @name Convenience Reporting Functions
|
|
|
|
** These convenience reporting functions are able to handle the bulk of Tidy's
|
|
|
|
** necessary reporting, and avoid the danger of using a variadic if you are
|
|
|
|
** unfamiliar with Tidy.
|
|
|
|
*/
|
2017-09-02 21:29:56 +00:00
|
|
|
/** @{ */
|
|
|
|
|
|
|
|
|
2017-09-04 21:35:57 +00:00
|
|
|
void TY_(ReportAccessError)( TidyDocImpl* doc, Node* node, uint code );
|
2017-09-02 21:29:56 +00:00
|
|
|
void TY_(ReportAttrError)(TidyDocImpl* doc, Node *node, AttVal *av, uint code);
|
2017-09-02 22:00:46 +00:00
|
|
|
void TY_(ReportBadArgument)( TidyDocImpl* doc, ctmbstr option );
|
2017-09-04 19:28:08 +00:00
|
|
|
void TY_(ReportEntityError)( TidyDocImpl* doc, uint code, ctmbstr entity, int c );
|
2017-09-04 15:24:48 +00:00
|
|
|
void TY_(ReportFileError)( TidyDocImpl* doc, ctmbstr file, uint code );
|
2017-09-04 19:50:45 +00:00
|
|
|
void TY_(ReportEncodingError)(TidyDocImpl* doc, uint code, uint c, Bool discarded);
|
2017-09-04 20:12:01 +00:00
|
|
|
void TY_(ReportEncodingWarning)(TidyDocImpl* doc, uint code, uint encoding);
|
|
|
|
void TY_(ReportMissingAttr)( TidyDocImpl* doc, Node* node, ctmbstr name );
|
2017-09-04 20:38:07 +00:00
|
|
|
void TY_(ReportSurrogateError)(TidyDocImpl* doc, uint code, uint c1, uint c2);
|
|
|
|
void TY_(ReportUnknownOption)( TidyDocImpl* doc, ctmbstr option );
|
2017-09-02 21:29:56 +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
|
|
|
/** @} */
|
2017-09-19 19:07:52 +00:00
|
|
|
/** @name General Dialogue Writing
|
|
|
|
** These functions produce dialogue output such as individual messages, or
|
|
|
|
** several messages in summary form.
|
|
|
|
*/
|
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
|
|
|
|
2017-09-19 19:07:52 +00:00
|
|
|
/**
|
|
|
|
* Emits a single dialogue message, and is capable of accepting a variadic
|
|
|
|
* that is passed to the correct message formatter as needed.
|
|
|
|
*/
|
2017-09-08 01:06:44 +00:00
|
|
|
void TY_(Dialogue)( TidyDocImpl* doc, uint code, ... );
|
2017-09-19 19:07:52 +00:00
|
|
|
|
|
|
|
|
|
|
|
/** @} */
|
|
|
|
/** @name Output Dialogue Information */
|
|
|
|
/** @{ */
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*/
|
2017-02-13 19:29:47 +00:00
|
|
|
void TY_(ErrorSummary)( TidyDocImpl* doc );
|
2017-09-19 19:07:52 +00:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Outputs document HTML version and version-related information as the final
|
|
|
|
* report(s) in the report table.
|
|
|
|
* Called by `tidyRunDiagnostics()`, from console.
|
|
|
|
* Called by `tidyDocReportDoctype()`, currently unused.
|
|
|
|
*/
|
2017-09-04 20:49:49 +00:00
|
|
|
void TY_(ReportMarkupVersion)( TidyDocImpl* doc );
|
2017-09-19 19:07:52 +00:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Reports the number of warnings and errors found in the document as dialogue
|
|
|
|
* inforation.
|
|
|
|
* Called by `tidyRunDiagnostics()`, from console.
|
|
|
|
*/
|
2017-02-13 19:29:47 +00:00
|
|
|
void TY_(ReportNumWarnings)( TidyDocImpl* doc );
|
2011-11-17 02:44:16 +00:00
|
|
|
|
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
|
|
|
/** @} */
|
2017-09-19 19:07:52 +00:00
|
|
|
/** @} message_reporting group */
|
|
|
|
|
|
|
|
|
2017-10-08 14:47:03 +00:00
|
|
|
/***************************************************************************//**
|
2017-10-10 12:21:14 +00:00
|
|
|
** @defgroup message_mutinging Message Muting
|
2017-10-08 14:47:03 +00:00
|
|
|
**
|
2017-10-10 12:21:14 +00:00
|
|
|
** Message types included in the `mute` option will be be printed in
|
2017-10-08 14:47:03 +00:00
|
|
|
** messageOut().
|
|
|
|
**
|
|
|
|
** @{
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
/** Maintains a list of messages not to display. */
|
2017-10-10 12:21:14 +00:00
|
|
|
typedef struct _mutedMessages {
|
2017-10-08 14:47:03 +00:00
|
|
|
tidyStrings* list; /**< A list of messages that won't be output. */
|
|
|
|
uint count; /**< Current count of the list. */
|
|
|
|
uint capacity; /**< Current capacity of the list. */
|
2017-10-10 12:21:14 +00:00
|
|
|
} TidyMutedMessages;
|
2017-10-08 14:47:03 +00:00
|
|
|
|
|
|
|
|
2017-10-10 12:21:14 +00:00
|
|
|
/** Frees the list of muted messages.
|
2017-10-08 14:47:03 +00:00
|
|
|
** @param doc The Tidy document.
|
|
|
|
*/
|
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
|
|
|
/** Adds a new message ID to the list of muted messages.
|
2017-10-08 14:47:03 +00:00
|
|
|
** @param doc The Tidy document.
|
2017-10-20 00:27:12 +00:00
|
|
|
** @param opt The option that is defining the muted message.
|
2017-10-08 14:47:03 +00:00
|
|
|
** @param name The message code as a string.
|
|
|
|
*/
|
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
|
|
|
|
2017-11-19 15:21:46 +00:00
|
|
|
/** Start an iterator for muted messages.
|
|
|
|
** @param doc The Tidy document.
|
|
|
|
** @returns Returns an iterator token.
|
|
|
|
*/
|
|
|
|
TidyIterator TY_(getMutedMessageList)( TidyDocImpl* doc );
|
|
|
|
|
|
|
|
/** Get the next priority attribute.
|
|
|
|
** @param doc The Tidy document.
|
|
|
|
** @param iter The iterator token.
|
|
|
|
** @returns The next priority attribute.
|
|
|
|
*/
|
|
|
|
ctmbstr TY_(getNextMutedMessage)( TidyDocImpl* doc, TidyIterator* iter );
|
|
|
|
|
2017-10-08 14:47:03 +00:00
|
|
|
|
2017-10-10 12:21:14 +00:00
|
|
|
/** @} message_muting group */
|
2017-10-08 14:47:03 +00:00
|
|
|
|
|
|
|
|
2017-09-19 19:07:52 +00:00
|
|
|
/***************************************************************************//**
|
|
|
|
** @defgroup message_keydiscovery Key Discovery
|
|
|
|
**
|
|
|
|
** LibTidy users may want to use `TidyReportCallback` to enable their own
|
|
|
|
** localization lookup features. Because Tidy's report codes are enums the
|
|
|
|
** specific values can change over time. Using these functions provides the
|
|
|
|
** ability for LibTidy users to use LibTidy's enum values as strings for
|
|
|
|
** lookup purposes.
|
|
|
|
**
|
|
|
|
** @{
|
|
|
|
******************************************************************************/
|
2017-02-13 19:29:47 +00:00
|
|
|
|
2016-01-15 04:06:15 +00:00
|
|
|
/**
|
2017-09-19 19:07:52 +00:00
|
|
|
* This function returns a string representing the enum value name that can
|
|
|
|
* be used as a lookup key independent of changing string values.
|
|
|
|
* `TidyReportCallback` will return this general string as the report
|
|
|
|
* message key.
|
2016-01-15 04:06:15 +00:00
|
|
|
*/
|
2017-02-13 19:29:47 +00:00
|
|
|
ctmbstr TY_(tidyErrorCodeAsKey)(uint code);
|
|
|
|
|
2017-03-16 20:46:01 +00:00
|
|
|
/**
|
|
|
|
* Given an error code string, return the integer value of it, or UINT_MAX
|
|
|
|
* as an error flag.
|
|
|
|
*/
|
|
|
|
uint TY_(tidyErrorCodeFromKey)(ctmbstr code);
|
|
|
|
|
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
|
|
|
|
* in Tidy's list of error codes that can be return with
|
|
|
|
* `TidyReportFilter3`.
|
|
|
|
* Items can be retrieved with getNextErrorCode();
|
2016-01-15 04:06:15 +00:00
|
|
|
*/
|
2017-10-04 02:31:55 +00:00
|
|
|
TidyIterator TY_(getErrorCodeList)(void);
|
2017-02-13 19:29:47 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the next error code having initialized the iterator
|
|
|
|
* with `getErrorCodeList()`. You can use tidyErrorCodeAsKey
|
|
|
|
* to determine the key for this value.
|
|
|
|
*/
|
|
|
|
uint TY_(getNextErrorCode)( TidyIterator* iter );
|
|
|
|
|
|
|
|
|
2017-09-19 19:07:52 +00:00
|
|
|
/** @} message_keydiscovery group */
|
|
|
|
/** @} internal_api addtogroup */
|
|
|
|
|
2017-02-13 19:29:47 +00:00
|
|
|
|
2011-11-17 02:44:16 +00:00
|
|
|
|
|
|
|
/* accessibility flaws */
|
|
|
|
|
|
|
|
#define BA_MISSING_IMAGE_ALT 1
|
|
|
|
#define BA_MISSING_LINK_ALT 2
|
|
|
|
#define BA_MISSING_SUMMARY 4
|
|
|
|
#define BA_MISSING_IMAGE_MAP 8
|
|
|
|
#define BA_USING_FRAMES 16
|
|
|
|
#define BA_USING_NOFRAMES 32
|
|
|
|
#define BA_INVALID_LINK_NOFRAMES 64 /* WAI [6.5.1.4] */
|
|
|
|
#define BA_WAI (1 << 31)
|
|
|
|
|
|
|
|
/* presentation flaws */
|
|
|
|
|
|
|
|
#define USING_SPACER 1
|
|
|
|
#define USING_LAYER 2
|
|
|
|
#define USING_NOBR 4
|
|
|
|
#define USING_FONT 8
|
|
|
|
#define USING_BODY 16
|
|
|
|
|
|
|
|
/* badchar bit field */
|
|
|
|
|
|
|
|
#define BC_VENDOR_SPECIFIC_CHARS 1
|
|
|
|
#define BC_INVALID_SGML_CHARS 2
|
|
|
|
#define BC_INVALID_UTF8 4
|
|
|
|
#define BC_INVALID_UTF16 8
|
|
|
|
#define BC_ENCODING_MISMATCH 16 /* fatal error */
|
|
|
|
#define BC_INVALID_URI 32
|
|
|
|
#define BC_INVALID_NCR 64
|
|
|
|
|
2017-09-29 15:25:17 +00:00
|
|
|
/* other footnote bit field (temporary until formalized) */
|
|
|
|
|
|
|
|
#define FN_TRIM_EMPTY_ELEMENT 1
|
|
|
|
|
2016-01-15 04:06:15 +00:00
|
|
|
/* Lexer and I/O Macros */
|
|
|
|
|
|
|
|
#define REPLACED_CHAR 0
|
|
|
|
#define DISCARDED_CHAR 1
|
|
|
|
|
|
|
|
|
2011-11-17 02:44:16 +00:00
|
|
|
#endif /* __MESSAGE_H__ */
|