| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
new processing job
|
| |
|
|
| |
output files
|
| |
|
|
| |
Do the `curlyCount` per file and not globally.
|
| |\ |
|
| | |\
| | |
| | | |
Handling digraph versus label
|
| | | |
| | |
| | |
| | |
| | | |
In case a label contains a backslash (at the end), the digrapgh statement remains unchanged, though with the label= this backslash is converted to a double backslash.
Especially at the end (just before the " this can lead to problems, making the handling uniform.
|
| | |\ \
| | | |
| | | | |
Conflict between RCS tag and (e.g.) php description
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In some languages the `$` is used to start a variable name (php, perl).
When having a description like:
```
<b>$RRDp::error_mode</b>, <b>$RRDp::error</b>
```
this will lead to a message like:
```
warning: found </b> at different nesting level (4) than expected (2)
```
because the part `$RRDp:` is seen as start of a RCS tag and runs till the next `$`.
Though the `::` indicates here a class / namespace separator and in case of `$...:` directly followed by a `:` this should not be seen as RCS tag.
|
| | |\ \ \
| | |/ /
| |/| | |
issue 7015 Parsing issue with @includedoc and @startuml
|
| | | | |
| | | |
| | | |
| | | | |
In case of `\includedoc` the `\n` was not handled on the first line (`@startuml`)
|
| | |\ \ \
| | | | |
| | | | | |
Ambiguous file name in file command
|
| | | | | |
| | | | |
| | | | |
| | | | | |
The file command has only one argument.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I some cases a file name is used with the `\file` command and this filename exists multiple times although the `\file` command is in the file itself (actually file name can be omitted).
Another possibility is that the file description is in another file in the same directory.
When file is not found or ambiguous, try to prepend the path of the current file to it and see if the file can be found.
Example is shown in the warnings file like:
```
gmic-2.6.1/gmic-qt/src/Common.h:3: warning: the name `Common.h' supplied as the second argument in the \file statement matches the following input files:
gmic-2.6.1/gmic-qt/src/Common.h
gmic-2.6.1/zart/include/Common.h
Please use a more specific name by including a (larger) part of the path!
```
and here it is quite clear and unambiguous which file is meant.
|
| | |\ \ \ \
| | | | | |
| | | | | | |
Speed up AppVeyor build by using miktex setup tool and activating build cache
|
| | | | |/ /
| | |/| | |
|
| |/ / / / |
|
| |/ / / |
|
| | | | |
|
| |\ \ \ |
|
| | |\ \ \
| | | | |
| | | | | |
enable debug for re-entrant lexers
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
constructor and assignment operator
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | | |
thomas-haller-issue6960_d
|
| | | | | | | |
|
| | | |/ / /
| | | | |
| | | | |
| | | | | |
for the same .dot file
|
| |/ / / /
| | | |
| | | | |
Take over changes from https://github.com/cmorty/doxygen/commit/647ce4713ce0c1c58f37c54f4491d7dff3fa2512
|
| |\ \ \ \ |
|
| | |\ \ \ \
| | |/ / /
| |/| | | |
More than 26 appendices in LaTeX manual
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The 1.8.15 manual had 26 examples but due to the fact that a new example was created we got 27 and thus the characters A-Z are not sufficient.
In a number of LaTeX versions this leads to messages like:
```
Appendix \GenericError { }{LaTeX Error: Counter too large}{See th
e LaTeX manual or LaTeX Companion for explanation.}{You've lost some text. Try
typing <return> to proceed.\MessageBreak If that doesn't work, type X <retu
rn> to quit.}.
! LaTeX Error: Counter too large.
```
Solution for this is to reorganize the examples a little bit. This is done here by means of the "groups":
- Style examples
- Language Examples
as a consequence also the sections / subsections etc had to go 1 level deeper and this is accomplished by defining a new environment in which the different sections go 1 level deeper.
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
cfriedt/feature/cfriedt/6955/allow-javadoc-style-comment-blocks-with-a-doxyfile-variable
Allow Javadoc-style comment blocks with a Doxyfile variable
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Javadoc allows comments like this (which I refer to as "banner" comments)
/*****************
*
*****************/
but doxygen does not recognize them.
Instead, the doxygen manual says to do this
/*************//**
*
****************/
which some users aren't even aware is required. It also behaves poorly with clang-format.
I'm proposing to add a Doxyfile boolean option JAVADOC_BANNER which will default to NO. When set to YES, it will consider the first and second comments above to be equivalent.
However, I don't believe that the JAVADOC_BANNER option should default to YES, as there are likely a number of projects who have used the former syntax with full expectation that it would *not* appear in their documentation.
At least having the JAVADOC_BANNER default to NO allows users to opt-in voluntarily by adding JAVADOC_BANNER = YES to their Doxyfile. If the consensus is to make it a default at a later time, first a warning can be added during build that should trigger users to modify their comment style, and then eventually the default could be set to JAVADOC_BANNER = YES, or the config option could be removed entirely and it would just always be enabled.
|
| | |\ \ \
| | | | |
| | | | | |
Missing debug statements sqlcode and xmlcode lexers
|
| | | | | |
| | | | |
| | | | |
| | | | | |
The messages for `doxygen -d lex` were missing in case of the sqlcode.l and xmlcode.l
|
| |/ / / / |
|
| | | | | |
|
| |\ \ \ \
| |/ / / |
|
| | |\ \ \
| | | | |
| | | | | |
Class definition with collections
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Class definitions can have collections and these can have strings e.g.:
class Url(namedtuple('Url', url_attrs)):
and this results in:
warning: Detected potential recursive class relation between class conda::_vendor::urllib3::util::url::Url and base class Url!
Strings are now possible and seen as strings.
See also (including example with namedtuble): https://docs.python.org/3/library/collections.html
|
| | |\ \ \ \
| | | | | |
| | | | | | |
Incorrect Reached end of file while still inside a (nested) comment for TCL / Python
|
| | | | |/ /
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
/ Python
In case we have in the comment (or in the code) of a TCL file of Python file a construct like:
```
proc get_suite {dir {sort 1}} {
set files [glob -nocomplain $dir/*.bin]
set files [glob -nocomplain $dir/*.ps]
}
```
we get the warning:
```
warning: Reached end of file while still inside a (nested) comment. Nesting level 2 (probable line reference: 3, 2)
```
although the '/*' construct has no special comment meaning in TCL / Python (comment signs '#' / '#' or '"""). So if a c-comment construct is found it is ignored for TCL and Python.
|
| |\ \ \ \ \
| |/ / / / |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
Incorrect output tag order
|
| | | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When we have the Mardown file:
```
# First heading level 1
Some text ...
```
we get in the HTML file:
```
...
<div class="PageDoc"><div class="header">
<div class="headertitle">
<div class="title">First heading level 1 </div> </div>
</div><!--header-->javascript">
<div class="contents">
<div class="textblock"><p>Some text ... </p>
</div></div><!-- PageDoc -->
</div><!-- contents -->
...
```
Here we see that the `PageDoc` is closed before the `Contents` although the `PageDoc` was opened before the `Contents`.
In this constellation it doesn't give problems as both translate to `</div>` tag and in other output formats nothing is outputted, but in case in another format something is outputted this might lead to problems also the comment is now so that is indicates the error.
|
| |\ \ \ \ \
| |/ / / / |
|
