| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
In the code a 'printf' has been replaced with an appropriate 'warn' call (and renamed a local variable to prevent conflicts)
|
|\
| |
| |
| | |
https://github.com/albert-github/doxygen into albert-github-feature/bug_inline_image
|
| |
| |
| |
| | |
Create the possibility of inline images with the `\image` command by means of the option `inline`.
|
|\ \
| | |
| | |
| | | |
https://github.com/albert-github/doxygen into albert-github-feature/issue_6517
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Added issue support for the different output types.
- Sources of the emoji
- based on the Unicode definition v11.0:
- https://unicode.org/emoji/charts/full-emoji-list.html
- http://www.unicode.org/emoji/charts/full-emoji-modifiers.html
- github definition list:
- https://api.github.com/emojis
- Input of emoji: :<test>: with the restriction that direct after the opening colon and direct before the closing colon no space is allowed
- doctokinizer.l, adding detection of emoji and new command `\:`
- doktokinizer.h, adding "word" type TK_EMOJI
- docparser.* handling of new "word" type TK_EMOJI (analogous to HTML Entities), handling of new command `\:`
- cmdmapper,cpp, cmdmapper.h, adding new command `\:`
- htmlentity.cpp, adding new definition required for new command `\:`
- Emoji
- emoji.cpp, emoji.h, class for handling emoji analogous to HTML Entities, including small directions on how to update the code when a new emoji is defined. Not everything is converted to lowercase for comparison and accents are removed.
- doxygen.cpp possibility to create list of supported emoji
- handling emoji for output types (analogous to HTML Entities), see documentation for different output types
- docparser.h, *docvisitor.*
- rtfdocvisitor.* converting output to UTF-16 (based on http://scruss.com/blog/2017/03/12/in-the-unlikely-event-you-need-to-represent-emoji-in-rtf-using-perl/)
- latexdocvisitor.*, handling arguments for emoji in output (see also latexgen.cpp for meaning of the arguments of doxygenemoji).
- latexgen.cpp, adding new latex command for doxygen (doxygenemoji) and prevent too many open file (code before documentclass)
- config.xml, definition of `LATEX_EMOJI_DIRECTORY` with path to images required for LaTeX output
- Documentation:
- emojisup.doc, user description
- commands.doc, description of new command `\:`
- index.doc, reference to emoji chapter
- xmlcmds.doc, adjust reference to next chapter as a new chapter is added
- Doxyfile*, adding emoji chapter
Build system
- CMakeLists.txt adding new files
|
|\ \ \
| | | |
| | | | |
Correcting labels for citations
|
| | |/
| |/|
| | |
| | |
| | | |
The labels for RTF and XML were incorrect due to the fact that the wrong branch was chosen in the code (the newAnchor was set for the results of the `\cite ` command as well).
Small readability issue with XML (when there are a lot of citations).
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
https://github.com/albert-github/doxygen into albert-github-feature/bug_warning_msg
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- In case an unknown command is given this was shown as a warning but not as normal text in the output, for this also a distinction between `\`and `@` commands has to be made
- corrected command name in warning messages when handling arguments
- making handling of some warning messages consistent
|
|\ \ \ \
| | | | |
| | | | | |
Possibility to have a \image command inside a <A> tag
|
| | |/ /
| |/| |
| | | |
| | | | |
Enable the possibility to have a `\image` command inside a <A> tag
|
| |_|/
|/| |
| | |
| | | |
Create possibility to copy the image automatically to the HTML directory, in case file cannot be found no warning is given (consistency).
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | | |
https://github.com/albert-github/doxygen into albert-github-feature/bug_667993
|
| | |
| | |
| | |
| | | |
Added underline possibility and strike through possibility for the different output formats insofar it is possible (other similar possibilities are not always possible for all output formats either).
|
|\ \ \
| |_|/
|/| | |
|
| | | |
|
|/ /
| |
| |
| |
| | |
Enable possibility to have image in a `<a>` tag.
Will only show in HTML as the `<img>` is only shown in HTML (as documented).
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Possibility to honor also the cell alignment when using Markdown tables for other formats (markdown.cpp, latexdocvisitor.cpp, lines: 1146, 1157, 1173)
latexdocvisitor.cpp:
- Possibility to nest tables to a further level when using LaTeX. It was only possible till level 2 (i.e. a longtabu followed buy a tabularx table). By placing tabularx in an extra set of brackets this is fixed (lines 938 and 951)
- tablarx environment cannot handle the headers as used for the longtabu table. A header line is in case of tabularx implemented by mimicking the header line.
- longtabu needs multiple times the header line (first and following), tabularx we only need 1 (line 998)
- no longtabu special headers (line 1092)
- tabularx cannot handle rowcolor, coloring done only with columncolor(line 1024, 1134, 1188)
- no necessity for longtabu to define column with for spanned columns / rows(line 1048, 1134, 1171)
|
|
|
|
|
|
|
|
|
| |
When using a not supported output format with the image command e.g.
\image man foo.png
we get the warning message:
warning: image type man specified as the first argument of man is not valid
this is corrected to:
warning: output format man specified as the first argument of image command is not valid
|
|\
| |
| | |
Bug 794509 - c# see langword broken
|
| |
| |
| |
| |
| | |
- code.l: The word 'null' was not recognized as reserved word
- docparser.l The attribute 'langword' should not generate a link but the 'langword' value as code.
|
|/
|
|
| |
In case an argument has been documented multiple times a warning message is given.
|
|\ |
|
| | |
|
| |
| |
| |
| | |
HTML output
|
|\ \
| | |
| | | |
Suppresses warning for XML <see langword="..."/>
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/ |
|
|
|
|
|
|
|
|
|
| |
This patch makes the handling of the \snippet and other commands consistent between the different languages (no line numbers anymore with python) and also introduces analogous to \includelineno the command \snippetlineno.
Some non relevant changes:
- *code.l Calculation of the end line was incorrect, in case of a snippet the end line was the number of lines of the snippet and not reltive to the start line.
- *code.l made consistent over the different laguages, enabling exBlock and inlineFragment
- testing/indexpage.xml in test 14 the \snippet command was used with python and giving line numbers, linenumbers are now gone (consistency)
|
|
|
|
| |
The CLANG compiler gave some warnings after pull request #503 ("Introducing commands includedoc and snippetdoc ") at places that are not / should not be reachable.
|
|
|
|
|
| |
Purpose to have the possibility to have repeating texts not repeated in the comments.
The commands include and snippet introduce code blocks whilst the commands includedoc and snippetdoc inclode the text as is and it will be parsed by doxygen.
|
| |
|
|
|
|
| |
improve performance
|
|
|
|
| |
Made 'cls' parameter analogous to the 'self' parameter. See also https://www.python.org/dev/peps/pep-0008 (paragraph: Function and method arguments)
|
| |
|
| |
|
| |
|
|
|
|
| |
Extended / corrected some error messages
|
| |
|
| |
|
|\
| |
| | |
docparser: warn when finding a documented empty return type
|
| |
| |
| |
| |
| |
| |
| | |
There is an example on pg24 of [1] where a libclang based comment parser
emits a warning for a documented empty return type.
[1] "Parsing Documentation Comments in Clang" http://llvm.org/devmtg/2012-11/Gribenko_CommentParsing.pdf
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a number of instances we don't get the filename of where the error occurs but a name or even unknown between <> e.g.
<fie_p2>:1: warning: parameters of member fie_p2 are not (all) documented
<error>:1: warning: parameters of member p1.error are not (all) documented
<unknown>:1: warning: Member fie_p3 (function) of class p3::int1_p3 is not documented.
This patch tries to overcome this problem by providing the right file:
.../p2.h:8: warning: parameters of member fie_p2 are not (all) documented
.../p1.py:7: warning: parameters of member p1.error are not (all) documented
.../p3.f90:3: warning: Member fie_p3 (function) of class p3::int1_p3 is not documented.
|