summaryrefslogtreecommitdiffstats
path: root/testing/032
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #624 from mosra/xml-page-briefdescriptionDimitri van Heesch2017-12-241-0/+2
|\ | | | | Provide page brief in <briefdescription> of XML output
| * Provide page brief in <briefdescription> of XML output.Vladimír Vondruš2017-11-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | Until now the brief description of pages was prepended to the <detaileddescription> element and the <briefdescription> element was not present at all, which meant there was no easy way to extract the brief description for purposes of creating a page index, for example. With this patch, the brief description is included in both <briefdescription> and <detaileddescription>, thus duplicated, to avoid backwards compatibility issues.
* | Encode invalid XML characters instead of skipping them.Vladimír Vondruš2017-11-251-1/+1
|/ | | | | | | | | | | | | | | | | | | The <sp> element in <programlisting> has a new optional attribute `value`, which contains value of given invalid ASCII character. In case of space, the `value` attribute is omitted. Use cases for this: including snippets of *very esoteric* languages, markup that makes use of the advanced ASCII formatting characters or for example highlighting a console output containing ANSI color codes (which is my case, in fact). Regarding backwards compatibility -- as files with such ASCII characters are very rare, I don't expect this minor difference in the output to be a problem. Besides that, such ASCII characters are often replaced by a space in many applications anyway. A test snippet was extended to contain a special character so this difference in behavior could be verified.
* Propagate language information to all <programlisting> XML elements.Vladimír Vondruš2017-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on work done in 141dbfd5a4f79c98da14a1b414c6db4e1b34618b through ed9acb6e1bb81a2eec334180f7b8c1bf0598b444 and makes a few behavioral changes to it. There's a new attribute called `filename` and the `language` was removed, because it could provide misleading information. This allows for more flexibility on the user side. In particular: * For historical reasons, `*.txt` files are marked by Doxygen as C++ (see https://bugzilla.gnome.org/show_bug.cgi?id=760836 for details). In particular, code snippet included from a CMakeLists.txt file would be marked and highlighted as C++. So in this case, the language attribute would be very misleading. * Doxygen is aware only of a very small subset of languages and thus a lot of information can be lost when relying on its extension-to-language-name conversion -- in particular, all extensions that are not recognized are assumed to be C++. On the other hand, putting more effort into its language detection algorithms is not worth the time, as there will always be new languages that fail to detect. So let's leave that on the user of the XML output instead. * Using just file extension is not enough, it has to be a full filename. For example, `*.txt` can be either a plain text file or a `CMakeLists.txt`. * The path is not stripped from the filename, as it also may contain additional information that helps to detect the language better. In addition to that, filenames of code snippets included via the \include command and related are propagated to the <programlisting> element as well. With this change, (1) code snippets using simply \code some code \endcode will not produce any `filename` attribute and it's up to the user what to do -- assume C++, detect language from contents or not highlight anything. <programlisting> some code </programlisting> (2) Code snippets using \code{.cmake} some code \endcode will produce the following: <programlisting filename=".cmake"> some code </programlisting> (3) And finally, \include, \dontinclude and related \skip, \skipline etc. commands \include path/to/some-file.py will produce <programlisting filename="path/to/some-file.py"> some code </programlisting> The tests were updated to check all three cases. On the user side, when using Pygments for example, it's then just a matter of calling pygments.lexers.find_lexer_class_for_filename() with value of the `filename` attribute value and optionally also the code snippet for additional language analysis.
* Added regression test suiteDimitri van Heesch2013-07-191-0/+10