extract more api data via some doxy settings and test to comments

This commit is contained in:
Pedro 2015-03-05 05:14:21 +00:00
parent 4a5b360847
commit 81187629c3
3 changed files with 23 additions and 22 deletions

View file

@ -113,7 +113,7 @@ ABBREVIATE_BRIEF =
# Doxygen will generate a detailed section even if there is only a brief
# description.
ALWAYS_DETAILED_SEC = NO
ALWAYS_DETAILED_SEC = YES
# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
# inherited members of a class in the documentation of that class as if those
@ -158,7 +158,7 @@ SHORT_NAMES = NO
# comments will behave just like regular Qt-style comments
# (thus requiring an explicit @brief command for a brief description.)
JAVADOC_AUTOBRIEF = NO
JAVADOC_AUTOBRIEF = YES
# If the QT_AUTOBRIEF tag is set to YES then Doxygen will
# interpret the first line (until the first dot) of a Qt-style
@ -166,7 +166,7 @@ JAVADOC_AUTOBRIEF = NO
# will behave just like regular Qt-style comments (thus requiring
# an explicit \brief command for a brief description.)
QT_AUTOBRIEF = NO
QT_AUTOBRIEF = YES
# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
# treat a multi-line C++ special comment block (i.e. a block of //! or ///
@ -174,7 +174,7 @@ QT_AUTOBRIEF = NO
# The new default is to treat a multi-line C++ comment block as a detailed
# description. Set this tag to YES if you prefer the old behaviour instead.
MULTILINE_CPP_IS_BRIEF = NO
MULTILINE_CPP_IS_BRIEF = YES
# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
# member inherits the documentation from any documented member that it
@ -307,7 +307,7 @@ SUBGROUPING = YES
# @ingroup) instead of on a separate page (for HTML and Man pages) or
# section (for LaTeX and RTF).
INLINE_GROUPED_CLASSES = NO
INLINE_GROUPED_CLASSES = YES
# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and
# unions with only public data fields will be shown inline in the documentation
@ -316,7 +316,7 @@ INLINE_GROUPED_CLASSES = NO
# structs, classes, and unions are shown on a separate page (for HTML and Man
# pages) or section (for LaTeX and RTF).
INLINE_SIMPLE_STRUCTS = NO
INLINE_SIMPLE_STRUCTS = YES
# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum
# is documented as struct, union, or enum with the name of the typedef. So
@ -350,23 +350,23 @@ LOOKUP_CACHE_SIZE = 0
# Private class members and static file members will be hidden unless
# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
EXTRACT_ALL = NO
EXTRACT_ALL = YES
# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
# will be included in the documentation.
EXTRACT_PRIVATE = NO
EXTRACT_PRIVATE = YES
# If the EXTRACT_PACKAGE tag is set to YES, all members with package or
# internal scope will be included in the documentation.
# The default value is: NO.
EXTRACT_PACKAGE = NO
EXTRACT_PACKAGE = YES
# If the EXTRACT_STATIC tag is set to YES all static members of a file
# will be included in the documentation.
EXTRACT_STATIC = NO
EXTRACT_STATIC = YES
# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
# defined locally in source files will be included in the documentation.
@ -379,7 +379,7 @@ EXTRACT_LOCAL_CLASSES = YES
# the interface are included in the documentation.
# If set to NO (the default) only methods in the interface are included.
EXTRACT_LOCAL_METHODS = NO
EXTRACT_LOCAL_METHODS = YES
# If this flag is set to YES, the members of anonymous namespaces will be
# extracted and appear in the documentation as a namespace called
@ -798,7 +798,7 @@ USE_MDFILE_AS_MAINPAGE =
# Note: To get rid of all source code in the generated output, make sure also
# VERBATIM_HEADERS is set to NO.
SOURCE_BROWSER = NO
SOURCE_BROWSER = YES
# Setting the INLINE_SOURCES tag to YES will include the body
# of functions and classes directly in the documentation.

View file

@ -30,18 +30,19 @@
\htmlinclude tidy5.cmd.txt
</pre>
\page tidy5_lib tidy5lib
\page TidyLib TidyLib
- \b TidyLib is easy to integrate. Because of the near universal adoption of C linkage, a C interface may be called from a great number of programming languages.
- \b TidyLib - is easy to integrate. Because of the near universal adoption of C linkage, a C interface may be called from a great number of programming languages.
- \b TidyLib was designed to use opaque types in the public interface. This allows the application to just pass an integer around and the need to transform data types in different languages is minimized. As a results its straight-forward to write very thin library wrappers for C++, Pascal, and COM/ATL.
- \b TidyLib - is designed to use opaque types in the public interface. This allows the application to just pass an integer around and the need to transform data types in different languages is minimized. As a results its straight-forward to write very thin library wrappers for C++, Pascal, and COM/ATL.
- \b TidyLib eats its own dogfood. HTML Tidy links directly to TidyLib.
- \b TidyLib - eats its own dogfood. HTML Tidy links directly to TidyLib.
- \b TidyLib is Thread Safe and Re-entrant. Because there are many uses for HTML Tidy - from content validation, content scraping, conversion to XHTML - it was important to make TidyLib run reasonably well within server applications as well as client side.
- \b TidyLib - is Thread Safe and Re-entrant. Because there are many uses for HTML Tidy - from content validation, content scraping, conversion to XHTML - it was important to make TidyLib run reasonably well within server applications as well as client side.
- \b TidyLib uses adaptable I/O. As part of the larger integration strategy it was decided to fully abstract all I/O. This means a (relatively) clean separation between character encoding processing and shovelling bytes back and forth. Internally, the library reads from sources and writes to sinks. This abstraction is used for both markup and configuration “files”. Concrete implementations are provided for file and memory I/O, and new sources and sinks may be provided via the public interface.
- \b TidyLib - uses adaptable I/O. As part of the larger integration strategy it was decided to fully abstract all I/O. This means a (relatively) clean separation between character encoding processing and shovelling bytes back and forth. Internally, the library reads from sources and writes to sinks. This abstraction is used for both markup and configuration “files”. Concrete implementations are provided for file and memory I/O, and new sources and sinks may be provided via the public interface.
\section example_hello Example
\code{.c}
#include <tidy.h>;
#include <buffio.h>;
@ -50,7 +51,7 @@
int main(int argc, char **argv )
{
const char* input = "<title>Foo</title><p>Foo!";
const char* input = "<title>Hello</title><p>World!";
TidyBuffer output = {0};
TidyBuffer errbuf = {0};
int rc = -1;

View file

@ -160,7 +160,7 @@ struct _TidyAllocator;
/** The allocator **/
typedef struct _TidyAllocator TidyAllocator;
/** An allocator's function table. All functions here must
/** An allocator's function table. All functions here must
be provided.
*/
struct _TidyAllocatorVtbl {
@ -187,7 +187,7 @@ struct _TidyAllocatorVtbl {
/** An allocator. To create your own allocator, do something like
the following:
\code
typedef struct _MyAllocator {
TidyAllocator base;
...other custom allocator state...
@ -213,7 +213,7 @@ struct _TidyAllocatorVtbl {
allocator.base.vtbl = &amp;MyAllocatorVtbl;
...initialise allocator specific state...
doc = tidyCreateWithAllocator(&allocator);
...
\endcode
Although this looks slightly long winded, the advantage is that to create
a custom allocator you simply need to set the vtbl pointer correctly.