doxygen-develop — List for discussing new features, submitting patches, etc.

[Doxygen-develop] Another RPM Server

[Kevin M. <ke...@pl...>]

Hello everyone.

I'd like to tell everyone about my server that is hosting doxygen RPMs. 
  All RPMs on my server were built by me.  It's address is currently:

http://66.24.29.1/

You'll find doxygen RPMs for the i386 and the i686 platforms, as well as 
the source tarballs.  I hope my server gets added to the doxygen RPM 
list to make things more convenient to newbies.

I will also make RPMs for doxygen as new releases of doxygen come out, 
and keep releases as old as the current release (1.4.4) available to the 
general public.

- KJM

RE: [Doxygen-develop] suggestion: latex formula tags (f$,f[,f{) should imply verbatim

[Michael M. <Mic...@tt...>]

Hi there,

This is listed as a bug in Bugzilla too:
http://bugzilla.gnome.org/show_bug.cgi?id=304339 

I wondered if a possible workaround would be to use the LaTeX \newcommand
option to alias \dot to something that Doxygen won't pick on.  The
\newcommand directive can be placed in some file that is then referenced
from the Doxygen input file using the EXTRA_PACKAGES, or it may be enough to
put it in a \latexonly ... \endlatexonly block. 

Alternatively from Bugzilla, it looks as though Dimitri is planning to fix
it by the next CVS update.

Regards,

Mike

> -----Original Message-----
> From: dox...@li... [mailto:doxygen-develop-
> ad...@li...] On Behalf Of Ethan Tira-Thompson
> Sent: 06 August 2005 22:32
> To: dox...@li...
> Subject: [Doxygen-develop] suggestion: latex formula tags (f$,f[,f{)
> should imply verbatim
> 
> It's really annoying when you try to do stuff like this:
> /*!
>   @brief Delta torque due to delta joint position.
>   This function computes \f$S_2(q, \dot{q}, \ddot{q})\delta q\f$.
> */
> 
> but that "\dot" in the formula causes doxygen to complain:
> Warning: reached end of file while inside a dot block!
> ...and then the documentation gets hosed.
> 
> I don't know how best to fix this -- if I try to manually stick
> \verbatim in the fomula:
> /*!  \f$\verbatim S_2(q, \dot{q}, \ddot{q})\delta q\endverbatim\f$  */
> then somehow latex gets ahold of the verbatim tag and has throws its own
> error.  So perhaps the formula is already verbatim, and just the \dot
> command is getting through somehow?
> 
> Anyway, a work around would be nice if I'm missing something.
> 
> Thanks
>  -ethan
> 
> PS I just updated my patch for bug 162968 to work with 1.4.4:
>   http://bugzilla.gnome.org/show_bug.cgi?id=162968
> If there's any feedback on that, I'm the one to talk to, though probably
> should do it through the bugzilla page.
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] suggestion: latex formula tags (f$,f[,f{) should imply verbatim

[Ethan Tira-T. <ej...@an...>]

It's really annoying when you try to do stuff like this:
/*!
  @brief Delta torque due to delta joint position.
  This function computes \f$S_2(q, \dot{q}, \ddot{q})\delta q\f$.
*/

but that "\dot" in the formula causes doxygen to complain:
Warning: reached end of file while inside a dot block!
...and then the documentation gets hosed.

I don't know how best to fix this -- if I try to manually stick 
\verbatim in the fomula:
/*!  \f$\verbatim S_2(q, \dot{q}, \ddot{q})\delta q\endverbatim\f$  */
then somehow latex gets ahold of the verbatim tag and has throws its own 
error.  So perhaps the formula is already verbatim, and just the \dot 
command is getting through somehow?

Anyway, a work around would be nice if I'm missing something.

Thanks
 -ethan

PS I just updated my patch for bug 162968 to work with 1.4.4:
  http://bugzilla.gnome.org/show_bug.cgi?id=162968
If there's any feedback on that, I'm the one to talk to, though probably 
should do it through the bugzilla page.

[Doxygen-develop] Firefox performance

[Nikolay M. <N.M...@te...>]

Is there anything that could be done to the HTML output of doxygen to
improve performance on Firefox?
=20
On projects with lots of source code doxygen seems to generate
JavaScript which makes Firefox struggle.
=20
Here is the bug report in mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=3D218308
=20
That bug report suggests one improvement comment 6. But perhaps a rework
of the html is more desirable?

[Doxygen-develop] Sponsoring of some developement

[Drago B. <dra...@im...>]

Dear all,

Doxygen is quite useful to us for documenting the programming code we develop
and we are glad that you offer it to the community for general benefit.

However, there are some small improvements for which we thing that would make
it even more useful, at least for us they are of some importance. They 
include the
following.

* Enabling a customizable support for multilingual characters in both HTML and
LaTeX. In particular we are interested in (LaTeX equivalents of) \v{c}, 
\v{s} and \v{z},
but a general customizable solution which would map particular UTF-8 
characters
or particular ANSI sequences of characters in input to specified sequences of
characters in HTML and to specified sequences of characters in LaTeX would be
a better solution.

* Upgrading/updating the Slovenian language pack. For the purpose of this issue
this email is CCed to the maintainer of Slovenian translation Matja"z 
Ostrover"snik;
hopefully he will be able to respond.

We would be very much interested in having those issues resolved and are 
prepared
to sponsor them. Please contact me, if you are willing to help.

I shall add that I have looked at the documentation to see whether such 
features may
already be implemented, but I did not find out about them. If I missed 
something, please
advise me where to look.

Thank you,
Drago Bokal

Institute of mathematics, physics and mechanics
University of Ljubljana
Slovenia

Re: [Doxygen-develop] How to support a new language???

[Dimitri v. H. <di...@st...>]

Hi Enno,

On Fri, Jul 22, 2005 at 04:04:30PM +0200, Enno Bartels wrote:
> Hi 
> 
> I would like to kick off  to support a new 
> language in doxygen, like ADA (.adb, .ads)or Matlab (.pro)
> 
> So this it the way it should be done - is that right?!
> 
> 1. So the first thing is to write a new parser and
>     adapt the "Makefile.in"
>    1.1. src/adacode.h
>    1.2. src/adacode.l    ->   Makefile (flex)   ->   src/adacode.cpp     
>  
>    1.3. src/adascanner.h
>    1.4. src/adascanner.l    ->   Makefile (flex)   ->    src/adascanner.cpp
> 
>     OR for matlab
> 
>    1.1. src/matlabcode.h
>    1.2. src/matlabcode.l    ->   Makefile (flex)   ->   src/matlabcode.cpp     
>  
>    1.3. src/matlabscanner.h
>    1.4. src/matlabscanner.l    ->   Makefile (flex)   ->    src/matlabscanner.cpp

That's correct.

>    Question: 
>        a.) What does the "XXXscanner.l" and 
>             what the "XXXcode.l" program
>             module?

The scanner should scan the input files (they are fed to the scanner one
by one at the stage where doxygen says Parsing ....).

The scanner should build a tree of nodes of type Entry (the root of the
tree is provided by the caller, the scanner should just add children to
the root or other child nodes). 

Each entry represents a "thing" (class, variable, namespace, function, etc) 
which can be documented (along with the documentation if available) or 
just documentation (if the documentation contains structural commands 
like @class or @fn). 

The scanner should extract comment blocks and pass them to the comment scanner
(see commentscan.h). Furthermore, the scanner should fill in as much
information about a "thing" as possible, but at least the section field
and the name.

The code file should contains the source code scanner, which is presented
with strings representing the input files (if SOURCE_BROWSER is YES) 
but also with the contents of \code ... \endcode blocks.
It should do syntax highlighting and cross-referencing of the code 
with the documentation and can use the information stored in FileDef
for that (i.e. getSourceDefinition(lineNr) and getSourceMember(lineNr)).
For proper cross-referencing both scanner.l and code.l should keep 
track of the current line number.

> 
>        b.) What does they need for a start version? 

You mean what is the minimum? The code parser can just pass the file 
(provided as a string) through CodeOutputInterface::codify. 

The scanner should at least add some Entry nodes to the root node.

>        c.) 
> 
> 
> 2. Register the new parser to the right extension
>      File:  src/doxygen.cpp     Line: 7765
> 
>     2.1. Doxygen::parserManager->registerParser(".adb",new AdaLanguageScanner);
>     2.2. Doxygen::parserManager->registerParser(".ads",new AdaLanguageScanner);
> 
>     or with matlab:
> 
>     2.1. Doxygen::parserManager->registerParser("pro",new MatlabLanguageScanner);

Correct.

>  3. Write some test case of ada or Matlab code
>      3.1. First test with only a main
>      3.2. Second test with hello world
>      3.3. etc.
> 
> So is this the right way to do this ?

Yes, I believe so.

Regards,
  Dimitri

[Doxygen-develop] How to support a new language???

[Enno B. <enn...@t-...>]

Hi 

I would like to kick off  to support a new 
language in doxygen, like ADA (.adb, .ads)or Matlab (.pro)

So this it the way it should be done - is that right?!

1. So the first thing is to write a new parser and
    adapt the "Makefile.in"
   1.1. src/adacode.h
   1.2. src/adacode.l    ->   Makefile (flex)   ->   src/adacode.cpp     
 
   1.3. src/adascanner.h
   1.4. src/adascanner.l    ->   Makefile (flex)   ->    src/adascanner.cpp

    OR for matlab

   1.1. src/matlabcode.h
   1.2. src/matlabcode.l    ->   Makefile (flex)   ->   src/matlabcode.cpp     
 
   1.3. src/matlabscanner.h
   1.4. src/matlabscanner.l    ->   Makefile (flex)   ->    src/matlabscanner.cpp


   Question: 
       a.) What does the "XXXscanner.l" and 
            what the "XXXcode.l" program
            module?

       b.) What does they need for a start version? 

       c.) 


2. Register the new parser to the right extension
     File:  src/doxygen.cpp     Line: 7765

    2.1. Doxygen::parserManager->registerParser(".adb",new AdaLanguageScanner);
    2.2. Doxygen::parserManager->registerParser(".ads",new AdaLanguageScanner);

    or with matlab:

    2.1. Doxygen::parserManager->registerParser("pro",new MatlabLanguageScanner);

 3. Write some test case of ada or Matlab code
     3.1. First test with only a main
     3.2. Second test with hello world
     3.3. etc.

So is this the right way to do this ?

Any comments requested!!


Thanks for listening
Enno

[Doxygen-develop] Adding generic sub-commands

[Michael M. <Mic...@tt...>]

Hi there,

I really like the ability to use \dot to inline state transition diagrams -
it's a great usage of Graphviz!

In addition to this I would be keen to add a generic command runner to allow
other apps that can generate images or text to be used.  E.g.

/**
 * blah blah
 * \icmd html gnuplot $in
 * set terminal png color
 * set out $out
 * plot sin(x) 
 * quit
 * \endicmd
 */

Some expansion of things like $in, $out and maybe something like $type could
be used by ensure that the input and output can be supplied and accessed by
Doxygen, as well as allowing the command or script to generate the desired
output type (e.g. png or eps).

What do people think, would this be cool?  

Regards,

Mike

[Doxygen-develop] [PATCH] Improved HTML separation of member documentation

[Jim E. <ev...@sn...>]

Hello,
	We are trying to use doxygen to generate API documentation.  One of the
problems is that the HTML member documentation is very difficult to
peruse because there is no good delineation between member sections,
making it hard for the eye to settle on a single section.  The following
simple patch adds a horizontal line (<hr>) and a title (<h3>) before
each member section.  I find this much easier to read.

-Jim

RE: [Doxygen-develop] \sideeffect

[Michael M. <Mic...@tt...>]

Hi,

Can=92t this be done already as described in the manual:

http://www.stack.nl/~dimitri/doxygen/config.html#cfg_aliases

Regards,

Mike

________________________________________
From: dox...@li...
[mailto:dox...@li...] On Behalf Of Joseph
Turian
Sent: 15 July 2005 22:49
To: dox...@li...
Subject: [Doxygen-develop] \sideeffect

I'd like to see a \sideeffect command for functions.
Would anybody else find this command useful?

=A0=A0 Joseph

--=20
http://www.cs.nyu.edu/~turian/=20

[Doxygen-develop] \sideeffect

[Joseph T. <tu...@gm...>]

I'd like to see a \sideeffect command for functions.
Would anybody else find this command useful?

Joseph

--=20
http://www.cs.nyu.edu/~turian/

[Doxygen-develop] Patch: Nicer configure output

[Enno B. <enn...@t-...>]

Hi

Added some echos for nicer and clearly 
arranged looking output from the
"configure" file. 
Maybe you do agree with me.

Look in the attached patch file.
It was created with
cvs diff -u configure > patch_2005.07.14_nicer_configure_output.txt

Thanks for listening

Enno

[Doxygen-develop] Patch: cvsignore files updated

[Enno B. <enn...@t-...>]

Hi

Did updated the .cvsignore files. 
Some new entries were missing. Added that.

Look in the attached patch file.
It was created with
cvs diff -u > patch_2005.07.14_cvsignore.txt       

Thanks for listening 
Enno

Re: [Doxygen-develop] Verilog support in Doxygen

[Dimitri v. H. <do...@gm...>]

T24gNy83LzA1LCBNb2hhbW1hZCBNdXNhIDxtb2hhbW1hZC5tdXNhQHhpbGlueC5jb20+IHdyb3Rl
Ogo+IAo+IAo+IEEgbnVtYmVyIG9mIHBlb3BsZSBoYXZlIGV4cHJlc3NlZCBpbnRlcmVzdCBpbiBz
dXBwb3J0aW5nIFZlcmlsb2cgaW4gRG94eWdlbi4KPiBXZSB3b3VsZCBsaWtlIHRvIGtpY2sgc3Rh
cnQgdGhpcyBpbml0aWF0aXZlIGFuZCB3ZSB3YW50ZWQgdG8gZmluZCBvdXQgaWYKPiB0aGVyZSBp
cyBhbnlvbmUgZWxzZSBpbnRlcmVzdGVkIGluIHBhcnRpY2lwYXRpbmcuIFdlIGFyZSBjdXJyZW50
bHkgYSBncm91cAo+IG9mIHRocmVlLiAKPiAKPiAgIAo+IAo+IEFueSBjb21tZW50cyBvciBpbnNp
Z2h0cyBhcmUgZ3JlYXRseSBhcHByZWNpYXRlZCBlc3BlY2lhbGx5IGZyb20gZGV2ZWxvcGVycwo+
IHdobyBhcmUgdHJ5aW5nIHRvIHN1cHBvcnQgbGFuZ3VhZ2VzIGxpa2UgTWF0bGFiLCBQZXJsLCBW
QiwgUHl0aG9uIIVldGMuIAo+CgpUbyBnZXQgc3RhcnRlZDoKCkkgdGhpbmsgaXQgaXMgaW1wb3J0
YW50IHRvIGZpbmQgYSBtYXBwaW5nIGZyb20gdGhlIGNvbmNlcHRzIGluIFZlcmlsb2cKdG8gdGhl
IG9uY2VzCnN1cHBvcnRlZCBieSBkb3h5Z2VuLiBEb3h5Z2VuIHN1cHBvcnRzIGNvbXBvdW5kcyAo
bmFtZXNwYWNlcywgY2xhc3NlcywKZmlsZXMsIGdyb3VwcywgcGFnZXMsIGRpcmVjdG9yaWVzKSBh
bmQgbWVtYmVycyAoZnVuY3Rpb25zLCBkZWZpbmVzLAp2YXJpYWJsZXMsIHR5cGVkZWZzLCBlbnVt
cykuIEFkZGluZyBuZXcgImNvbmNlcHRzIiBpcyBhIGxvdCBvZiB3b3JrIGFzCml0IGhhcyB0byBi
ZSBhZGRlZCBmb3IgYWxsIG91dHB1dCBmb3JtYXRzLCByZXF1aXJlcyBuZXcgaW5kaWNlcyBhbmQK
bmV3IHRleHQgdG8gYmUgdHJhbnNsYXRlZC4KClRha2UgdGhlIGxhdGVzdCBDVlMgdmVyc2lvbiBh
bmQgdGhlbiBsb29rIGF0IHNyYy9wYXJzZXJpbnRmLmggd2hpY2ggaXMKdGhlIGFic3RyYWN0IGlu
dGVyZmFjZSB0byB0aGUgbGFuZ3VhZ2UgcGFyc2VyLiBUaGVuIGxvb2sgYXQKc3JjL3B5c2Nhbm5l
ci5sIGFuZCBzcmMvcHljb2RlLmwgZm9yIGEgcmVsYXRpdmUgY2xlYW4gd2F5IGhvdyB0bwppbXBs
ZW1lbnQgYSBuZXcgcGFyc2VyIChmb3IgUHl0aG9uIGluIHRoZSBleGFtcGxlKS4KClJlZ2FyZHMs
CiAgRGltaXRyaQo=

Re: [Doxygen-develop] Running out of memory

[Dimitri v. H. <do...@gm...>]

On 7/7/05, Jacob Foshee <jf...@se...> wrote:
> =20
> Hello,=20
> I recently posted to the user list that we are running doxygen on a large
> project and it is running out of memory.  I might be able to contribute s=
ome
> work to get past this problem if it represents a bug, or some room for
> improvement.  So, I joined this list.=20
>  =20
> Does Doxygen normally use so much memory relative to the code it is parsi=
ng?
>  (3.5 MB of code -> 2+ GB of pagefile usage)=20
> Or is this an unusual case?=20

This doesn't seem like a normal amount. I would expect memory usage up to
about 100-300 Mb or so, but certainly not more. Is this during parsing alre=
ady?=20
and with which version of doxygen? Can you provide a stack trace at the=20
moment is it using a lot of memory (say >1Gb)?

>  =20
> If that is 'par for the course', then what options are there for preventi=
ng
> Doxygen from running out of memory?=20

Disabling features such as the source browser and search engine helps, but
in your case the problem is something else I think.

>  =20
> Along this line, I started to think that perhaps Doxygen could start to u=
se
> a robust database to manage the large amount of information it has to hol=
d
> onto (eg MySQL). I know this is a non-trivial step, so I'm not talking ab=
out
> it casually.=20
>  =20
> This could also be a step towards wish-list item #31 (Only regenerate tho=
se
> files that have changed.)=20
>  =20
> Alternatively, Doxygen could query asset managers for source code changes
> directly. (eg CVS, VSS, etc.) I assume that most people with large projec=
ts
> use some kind of source control. Does anyone have experience in this area=
?=20
>  =20
> And I'm sure you've considered a 3rd alternative where Doxygen could buil=
d
> doc-object files like a regular compiler.  (I guess these would be like t=
he
> tag files?)=20

I have been thinking about such options as well, but one of the main
problems are
the relations that doxygen makes between source files (think of the
cross references
in the source browser or the collaboration diagrams).=20

These make it very hard to determine which files (i.e. doc-objects) need to=
 be=20
updated beforehand (i.e. without first reading them all in memory, and
recomputing therelations). Without this there would only be a
performance decrease.

Regards,
  Dimitri

[Doxygen-develop] [PATCH] LaTeX reduced tableofcontents with LATEX_HIDE_INDICES=NO

[Michael M. <Mic...@tt...>]

Hi there,

I've been generating some beautiful LaTeX documentation but have found that
the table of contents that LaTeX adds is sometimes a little big and flat!  

For example, if LATEX_HIDE_INDICES=NO, the generated table of contents
duplicates the section indices, and additionally flattens out module
documentation.  The following is test input that illustrates this:

/** \defgroup Group0 This is group 0.
 @{ */
/** \defgroup Group1 This is group 1.
@{ */
/** \defgroup Group2 This is group 2.
@{ */
/** \defgroup Group3 This is group 3.
@{ */

int main();

/** @} */
/** @} */
/** @} */
/** @} */

With this, the modules index (page 5 if this is the only input file) looks
like the following:

Chapter 1
Module Index
1.1 Modules
Here is a list of all modules:
This is group 0. . . . . . . . . . . . . . . . . . . 3
   This is group 1 . . . . . . . . . . . . . . . . . 4
      This is group 2. . . . . . . . . . . . . . . . 5
         This is group 3 . . . . . . . . . . . . . . 6

Perfect!  But the main index (page 3) appears as the following:

Contents
1 Module Index 1
   This is group 0. . . . . . . . . . . . . . . . . . 3
   This is group 1. . . . . . . . . . . . . . . . . . 4
   This is group 2. . . . . . . . . . . . . . . . . . 5
   This is group 3. . . . . . . . . . . . . . . . . . 6   
2 Module Documentation 3

The hierarchy is lost on LaTeX, and these items are reproduced on page 3
under the Module Index in any case :)  The following patch makes the LaTeX
generated \tableofcontents limited to the top level headings only, such that
only the main sections are bought out and the contents appears as the
following:

Contents
1 Module Index 1
2 Module Documentation 3

This also has the benefit of reducing the size of this document if the
indices are very large.  I've done this with the LaTeX command
"\setcounter{tocdepth}{0}".

The patch is stored at: 
  http://www.mcternan.co.uk/Doxygen/hide-indices-small-toc-1.4.3.patch

Also reproduced here:

--- doxygen-1.4.3.orig/src/latexgen.cpp	2005-07-07 23:27:20.911176000 +0100
+++ doxygen-1.4.3/src/latexgen.cpp	2005-07-07 23:26:33.523035200 +0100
@@ -299,7 +299,21 @@
     << "\\end{titlepage}" << endl;
   if (!Config_getBool("COMPACT_LATEX")) t << "\\clearemptydoublepage\n";
   t << "\\pagenumbering{roman}\n";
+
+  // Generate the table of contents
+  if(Config_getBool("LATEX_HIDE_INDICES"))
+  {
   t << "\\tableofcontents\n";
+  }
+  else
+  {
+    // Create top level only index; each section has its own detailed index
+    t << "\\newcounter{tocdepthbak}\n";
+    t << "\\setcounter{tocdepthbak}{\\value{tocdepth}}\n";
+    t << "\\setcounter{tocdepth}{0}\n";
+    t << "\\tableofcontents\n";
+    t << "\\setcounter{tocdepth}{\\value{tocdepthbak}}\n";
+  }
   if (!Config_getBool("COMPACT_LATEX")) t << "\\clearemptydoublepage\n";
   t << "\\pagenumbering{arabic}\n";
 }


Regards,

Mike

[Doxygen-develop] Verilog support in Doxygen

[Mohammad M. <moh...@xi...>]

Hi!

 

A number of people have expressed interest in supporting Verilog in Doxygen.
We would like to kick start this initiative and we wanted to find out if
there is anyone else interested in participating. We are currently a group
of three.

 

Any comments or insights are greatly appreciated especially from developers
who are trying to support languages like Matlab, Perl, VB, Python .etc. 

 

Cheers,

Mohammad

[Doxygen-develop] Running out of memory

[Jacob F. <jf...@se...>]

Hello,
I recently posted to the user list that we are running doxygen on a =
large project and it is running out of memory.  I might be able to =
contribute some work to get past this problem if it represents a bug, or =
some room for improvement.  So, I joined this list.
=20
Does Doxygen normally use so much memory relative to the code it is =
parsing?  (3.5 MB of code -> 2+ GB of pagefile usage)
Or is this an unusual case?
=20
If that is 'par for the course', then what options are there for =
preventing Doxygen from running out of memory?
=20
Along this line, I started to think that perhaps Doxygen could start to =
use a robust database to manage the large amount of information it has =
to hold onto (eg MySQL). I know this is a non-trivial step, so I'm not =
talking about it casually.
=20
This could also be a step towards wish-list item #31 (Only regenerate =
those files that have changed.)
=20
Alternatively, Doxygen could query asset managers for source code =
changes directly. (eg CVS, VSS, etc.) I assume that most people with =
large projects use some kind of source control. Does anyone have =
experience in this area?
=20
And I'm sure you've considered a 3rd alternative where Doxygen could =
build doc-object files like a regular compiler.  (I guess these would be =
like the tag files?)
=20
Anyway, don't flame me for my pipedream-type post. ;-)  I'm just =
interested in where things are going, and where I might be able to help.
=20
Cheers and thanks for all your work,
Jacob Foshee
=20

[Doxygen-develop] Manual update: Use of bmeps from Miktex

[Michael M. <Mic...@tt...>]

Hi there,

There is a utility called bmeps that can convert png, jpg and pnm to eps.
This is quite useful when considering the use of the \image tag which needs
a bitmap format for HTML and eps for LaTex.

Is it worth mentioning this in the documentation for the \image tag, or at
least on the installation page?

I've got bmeps as a part of the MikTex installation, but it is available
here: http://bmeps.sourceforge.net/

Regards,

Mike

[Doxygen-develop] about Verilog support

[Xia G. <xi...@ma...>]

SGVsbG8sIGV2ZXJ5b25lIQ0KICAgDQogICBEb2VzIGRveHlnZW4gc3VwcG9ydCBWZXJpbG9nIGxh
bmd1YWdlPyBJZiBub3QsIEknbSBhYm91dCB0byB0cnkgdG8gYWRkIHRoaXMgc3VwcG9ydCBmb3Ig
aXQuIEJ1dCBJIGRvbid0IGtub3cgaG93IGRpZmZpY3VsdCBpdCBpcy4gQ2FuIGFueW9uZSBnaXZl
IG1lIHNvbWUgbm90ZXM/IFRoYW5rIHlvdSEJCQkNCg0KoaGhoaGhoaGhoaGhoaGhoVhpYSBHYW8N
CqGhoaGhoaGhoaGhoaGhoaF4aWFvZ2FvQG1haWxzLnRzaW5naHVhLmVkdS5jbg0KoaGhoaGhoaGh
oaGhoaGhoaGhoaEyMDA1LTA3LTA1DQo=

[Doxygen-develop] [Patch]: Improved Preprocessing of DOT input files

[Michael M. <Mic...@tt...>]

Hi,

I've improved the patch for preprocessing dot input files.  It now generates
an intermediate file (inputname.i), which is deleted/preserved based on the
setting of DOT_CLEANUP. 

Apply in the following manner:

$ tar -xzf doxygen-1.4.3.src.tar.gz
$ cd doxygen-1.4.3
$ patch -p1 < patchfile

The patch is available here: 
http://www.mcternan.co.uk/Doxygen/pre-proc-dot-1.4.3.patch

Also listed directly:

diff -Naurw doxygen-1.4.3.orig/addon/doxywizard/config.l
doxygen-1.4.3/addon/doxywizard/config.l
--- doxygen-1.4.3.orig/addon/doxywizard/config.l	2005-05-16
20:38:16.000000000 +0100
+++ doxygen-1.4.3/addon/doxywizard/config.l	2005-05-24
22:57:11.358347200 +0100
@@ -2491,6 +2491,16 @@
                     TRUE
                  );
   cb->addDependency("ENABLE_PREPROCESSING");
+  cb = addBool(
+                    "PREPROCESS_DOT_FILES",
+                    "If the PREPROCESS_DOT_FILES tag is set to YES then
doxygen's preprocessor \n"
+                    "will be called on all files that are about to be
passed to DOT.  This \n"
+                    "allows pre-processor protections to be added around
nodes such that build \n"
+                    "defines can add or hide graph nodes.  The default
option is NO such that \n"
+                    "compatibility with older versions of Doxygen is
maintained. \n",
+                    FALSE
+                 );
+  cb->addDependency("ENABLE_PREPROCESSING");
 
//--------------------------------------------------------------------------
---------------------
   addInfo(  "External","Configuration::additions related to external
references   ");
 
//--------------------------------------------------------------------------
---------------------
diff -Naurw doxygen-1.4.3.orig/src/config.l doxygen-1.4.3/src/config.l
--- doxygen-1.4.3.orig/src/config.l	2005-05-12 20:19:42.000000000 +0100
+++ doxygen-1.4.3/src/config.l	2005-05-24 22:56:52.050584000 +0100
@@ -2491,6 +2491,16 @@
                     TRUE
                  );
   cb->addDependency("ENABLE_PREPROCESSING");
+  cb = addBool(
+                    "PREPROCESS_DOT_FILES",
+                    "If the PREPROCESS_DOT_FILES tag is set to YES then
doxygen's preprocessor \n"
+                    "will be called on all files that are about to be
passed to DOT.  This \n"
+                    "allows pre-processor protections to be added around
nodes such that build \n"
+                    "defines can add or hide graph nodes.  The default
option is NO such that \n"
+                    "compatibility with older versions of Doxygen is
maintained. \n",
+                    FALSE
+                 );
+  cb->addDependency("ENABLE_PREPROCESSING");
 
//--------------------------------------------------------------------------
---------------------
   addInfo(  "External","Configuration::additions related to external
references   ");
 
//--------------------------------------------------------------------------
---------------------
diff -Naurw doxygen-1.4.3.orig/src/dot.cpp doxygen-1.4.3/src/dot.cpp
--- doxygen-1.4.3.orig/src/dot.cpp	2005-04-17 17:55:56.000000000 +0100
+++ doxygen-1.4.3/src/dot.cpp	2005-07-04 23:18:42.981606400 +0100
@@ -29,6 +29,8 @@
 #include "docparser.h"
 #include "debug.h"
 #include "pagedef.h"
+#include "pre.h"
+#include "bufstr.h"
 
 #include <qdir.h>
 #include <qfile.h>
@@ -2707,6 +2709,7 @@
                            const char *outFile,GraphOutputFormat format)
 {
   QCString absOutFile = outDir;
+  QCString *tempFile  = NULL;
 #ifdef _WIN32
   absOutFile+='\\';
 #else
@@ -2733,6 +2736,34 @@
   QCString imgExt = Config_getEnum("DOT_IMAGE_FORMAT");
   QCString imgName = (QCString)outFile+"."+imgExt;
 
+  // Preprocess the file if needed */
+  if(Config_getBool("PREPROCESS_DOT_FILES"))
+  {
+    BufStr ppBuf(512);
+
+    // Preprocess the input to the buffer
+    preprocessFile(inFile, ppBuf);
+
+    // Duplicate outFile and append ".i"
+    tempFile = new SCString(outFile);
+    tempFile->append(".i");
+
+    // Rewrite the buffer to the input file
+    QFile file(*tempFile);
+    if (!file.open(IO_WriteOnly))
+    {
+      err("Could not open file %s for writing\n", (const char *)tempFile);
+    }
+    else
+    {
+      file.writeBlock( ppBuf.data(), ppBuf.curPos() );
+      file.close();
+
+      // Switch inFile to the preprocessed tempFile
+      inFile = tempFile->data();
+    }
+  }
+
   DotRunner dotRun(inFile);
   if (format==BITMAP) 
     dotRun.addJob(imgExt,imgName);
@@ -2775,9 +2806,22 @@
 
   if (format==BITMAP) checkDotResult(imgName);
 
-  QDir::setCurrent(oldDir);
+  // Check if a temp file was created
+  if (tempFile)
+  {
+      // Delete the intermediate file if needed
+      if(Config_getBool("DOT_CLEANUP"))
+      {
+          QFile file(*tempFile);
+
+          file.remove();
 }
 
+      delete tempFile;
+  }
+
+  QDir::setCurrent(oldDir);}
+
  
 /*! Marco Dalla Gasperina [ma...@at...] added this to allow
  *  dotfiles to generate image maps.


Regards,

Mike

> -----Original Message-----
> From: dox...@li... [mailto:doxygen-develop-
> ad...@li...] On Behalf Of Michael McTernan
> Sent: 04 July 2005 18:08
> To: dox...@li...
> Subject: [Doxygen-develop] RE: Patch: Preprocessing DOT input files
> 
> Hi there,
> 
> I've made a few improvements to this such that it creates a separate ".i"
> file containing the preprocesed input.
> 
> Aside, I've also been building using Cygwin and -mno-cygwin to make native
> Win32 binaries, which works rather nicely (although needs a hack in
> qtools.pro.in to use the win32 files).
> 
> Anyone interested in these patches, or a binary with preprocessing
> functionality?
> 
> Regards,
> 
> Mike
> 
> > -----Original Message-----
> > From: Michael McTernan [mailto:Mic...@tt...]
> > Sent: 25 May 2005 00:03
> > To: 'dox...@li...'; 'di...@st...'
> > Subject: Patch: Preprocessing DOT input files
> >
> > Hi there,
> >
> > There was a post on the doxygen-users list a few days ago asking if it
> is
> > possible to do something like the following:
> >
> > /** blah blah
> > \dot
> > graph G {
> >   a -- b
> > #if defined(ENABLE_C)
> >   b -- c
> >   c -- a
> > #endif
> > }
> > \enddot
> >
> > */
> >
> > Basically this allows showing or hiding of nodes based on the pre-
> > processor defines.  As far as I've been able to workout, this cannot be
> > done without invoking an external pre-processor as part of a build step
> or
> > script.
> >
> > This feature is something I very much want, as I have a large diagram
> with
> > a few small parts which are optional depending on compile switches.  DOT
> > itself seems to like the idea of pre-processing as it ignores any lines
> > that start with a # character, so is safe to ignore and '#line' output,
> > were the pre-processor to make any.
> >
> > There follows a patch that adds an option "PREPROCESS_DOT_FILES" to
> allow
> > DOT input files to be preprocessed.  I would be very grateful to know if
> > this patch can be included in a future version or Doxygen, or whether it
> > needs any changes to be acceptable.
> >
> > The patch can be applied in the following way:
> >
> > $ tar -xzf doxygen-1.4.3.src.tar.gz
> > $ cd doxygen-1.4.3
> > $ patch -p1 < patchfile
> >
> > Here is the patch:
> >
> > diff -Naurw doxygen-1.4.3.orig/addon/doxywizard/config.l doxygen-
> > 1.4.3/addon/doxywizard/config.l
> > --- doxygen-1.4.3.orig/addon/doxywizard/config.l	2005-05-16
> > 20:38:16.000000000 +0100
> > +++ doxygen-1.4.3/addon/doxywizard/config.l	2005-05-24
> > 22:57:11.358347200 +0100
> > @@ -2491,6 +2491,16 @@
> >                      TRUE
> >                   );
> >    cb->addDependency("ENABLE_PREPROCESSING");
> > +  cb = addBool(
> > +                    "PREPROCESS_DOT_FILES",
> > +                    "If the PREPROCESS_DOT_FILES tag is set to YES then
> > doxygen's preprocessor \n"
> > +                    "will be called on all files that are about to be
> > passed to DOT.  This \n"
> > +                    "allows pre-processor protections to be added
> around
> > nodes such that build \n"
> > +                    "defines can add or hide graph nodes.  The default
> > option is NO such that \n"
> > +                    "compatibility with older versions of Doxygen is
> > maintained. \n",
> > +                    FALSE
> > +                 );
> > +  cb->addDependency("ENABLE_PREPROCESSING");
> >    //-------------------------------------------------------------------
> --
> > --------------------------
> >    addInfo(  "External","Configuration::additions related to external
> > references   ");
> >    //-------------------------------------------------------------------
> --
> > --------------------------
> > diff -Naurw doxygen-1.4.3.orig/src/config.l doxygen-1.4.3/src/config.l
> > --- doxygen-1.4.3.orig/src/config.l	2005-05-12 20:19:42.000000000
> +0100
> > +++ doxygen-1.4.3/src/config.l	2005-05-24 22:56:52.050584000 +0100
> > @@ -2491,6 +2491,16 @@
> >                      TRUE
> >                   );
> >    cb->addDependency("ENABLE_PREPROCESSING");
> > +  cb = addBool(
> > +                    "PREPROCESS_DOT_FILES",
> > +                    "If the PREPROCESS_DOT_FILES tag is set to YES then
> > doxygen's preprocessor \n"
> > +                    "will be called on all files that are about to be
> > passed to DOT.  This \n"
> > +                    "allows pre-processor protections to be added
> around
> > nodes such that build \n"
> > +                    "defines can add or hide graph nodes.  The default
> > option is NO such that \n"
> > +                    "compatibility with older versions of Doxygen is
> > maintained. \n",
> > +                    FALSE
> > +                 );
> > +  cb->addDependency("ENABLE_PREPROCESSING");
> >    //-------------------------------------------------------------------
> --
> > --------------------------
> >    addInfo(  "External","Configuration::additions related to external
> > references   ");
> >    //-------------------------------------------------------------------
> --
> > --------------------------
> > diff -Naurw doxygen-1.4.3.orig/src/dot.cpp doxygen-1.4.3/src/dot.cpp
> > --- doxygen-1.4.3.orig/src/dot.cpp	2005-04-17 17:55:56.000000000
> +0100
> > +++ doxygen-1.4.3/src/dot.cpp	2005-05-24 23:44:22.929947200 +0100
> > @@ -29,6 +29,8 @@
> >  #include "docparser.h"
> >  #include "debug.h"
> >  #include "pagedef.h"
> > +#include "pre.h"
> > +#include "bufstr.h"
> >
> >  #include <qdir.h>
> >  #include <qfile.h>
> > @@ -2714,6 +2716,24 @@
> >  #endif
> >    absOutFile+=outFile;
> >
> > +  // Preprocess the file if needed */
> > +  if(Config_getBool("PREPROCESS_DOT_FILES"))
> > +  {
> > +    BufStr ppBuf(512);
> > +
> > +    preprocessFile(inFile, ppBuf);
> > +
> > +    // Rewrite the buffer to the input file
> > +    QFile file(inFile);
> > +    if (!file.open(IO_WriteOnly))
> > +    {
> > +      err("Could not open file %s for writing\n",inFile);
> > +    }
> > +    file.writeBlock( ppBuf.data(), ppBuf.curPos() );
> > +    file.close();
> > +  }
> > +
> > +
> >    // chdir to the output dir, so dot can find the font file.
> >    QCString oldDir = convertToQCString(QDir::currentDirPath());
> >    // go to the html output directory (i.e. path)
> >
> >
> >
> > Cheers,
> >
> > Mike
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] RE: Patch: Preprocessing DOT input files

[Michael M. <Mic...@tt...>]

Hi there,

I've made a few improvements to this such that it creates a separate ".i"
file containing the preprocesed input.  

Aside, I've also been building using Cygwin and -mno-cygwin to make native
Win32 binaries, which works rather nicely (although needs a hack in
qtools.pro.in to use the win32 files).

Anyone interested in these patches, or a binary with preprocessing
functionality?

Regards,

Mike

> -----Original Message-----
> From: Michael McTernan [mailto:Mic...@tt...]
> Sent: 25 May 2005 00:03
> To: 'dox...@li...'; 'di...@st...'
> Subject: Patch: Preprocessing DOT input files
> 
> Hi there,
> 
> There was a post on the doxygen-users list a few days ago asking if it is
> possible to do something like the following:
> 
> /** blah blah
> \dot
> graph G {
>   a -- b
> #if defined(ENABLE_C)
>   b -- c
>   c -- a
> #endif
> }
> \enddot
> 
> */
> 
> Basically this allows showing or hiding of nodes based on the pre-
> processor defines.  As far as I've been able to workout, this cannot be
> done without invoking an external pre-processor as part of a build step or
> script.
> 
> This feature is something I very much want, as I have a large diagram with
> a few small parts which are optional depending on compile switches.  DOT
> itself seems to like the idea of pre-processing as it ignores any lines
> that start with a # character, so is safe to ignore and '#line' output,
> were the pre-processor to make any.
> 
> There follows a patch that adds an option "PREPROCESS_DOT_FILES" to allow
> DOT input files to be preprocessed.  I would be very grateful to know if
> this patch can be included in a future version or Doxygen, or whether it
> needs any changes to be acceptable.
> 
> The patch can be applied in the following way:
> 
> $ tar -xzf doxygen-1.4.3.src.tar.gz
> $ cd doxygen-1.4.3
> $ patch -p1 < patchfile
> 
> Here is the patch:
> 
> diff -Naurw doxygen-1.4.3.orig/addon/doxywizard/config.l doxygen-
> 1.4.3/addon/doxywizard/config.l
> --- doxygen-1.4.3.orig/addon/doxywizard/config.l	2005-05-16
> 20:38:16.000000000 +0100
> +++ doxygen-1.4.3/addon/doxywizard/config.l	2005-05-24
> 22:57:11.358347200 +0100
> @@ -2491,6 +2491,16 @@
>                      TRUE
>                   );
>    cb->addDependency("ENABLE_PREPROCESSING");
> +  cb = addBool(
> +                    "PREPROCESS_DOT_FILES",
> +                    "If the PREPROCESS_DOT_FILES tag is set to YES then
> doxygen's preprocessor \n"
> +                    "will be called on all files that are about to be
> passed to DOT.  This \n"
> +                    "allows pre-processor protections to be added around
> nodes such that build \n"
> +                    "defines can add or hide graph nodes.  The default
> option is NO such that \n"
> +                    "compatibility with older versions of Doxygen is
> maintained. \n",
> +                    FALSE
> +                 );
> +  cb->addDependency("ENABLE_PREPROCESSING");
>    //---------------------------------------------------------------------
> --------------------------
>    addInfo(  "External","Configuration::additions related to external
> references   ");
>    //---------------------------------------------------------------------
> --------------------------
> diff -Naurw doxygen-1.4.3.orig/src/config.l doxygen-1.4.3/src/config.l
> --- doxygen-1.4.3.orig/src/config.l	2005-05-12 20:19:42.000000000 +0100
> +++ doxygen-1.4.3/src/config.l	2005-05-24 22:56:52.050584000 +0100
> @@ -2491,6 +2491,16 @@
>                      TRUE
>                   );
>    cb->addDependency("ENABLE_PREPROCESSING");
> +  cb = addBool(
> +                    "PREPROCESS_DOT_FILES",
> +                    "If the PREPROCESS_DOT_FILES tag is set to YES then
> doxygen's preprocessor \n"
> +                    "will be called on all files that are about to be
> passed to DOT.  This \n"
> +                    "allows pre-processor protections to be added around
> nodes such that build \n"
> +                    "defines can add or hide graph nodes.  The default
> option is NO such that \n"
> +                    "compatibility with older versions of Doxygen is
> maintained. \n",
> +                    FALSE
> +                 );
> +  cb->addDependency("ENABLE_PREPROCESSING");
>    //---------------------------------------------------------------------
> --------------------------
>    addInfo(  "External","Configuration::additions related to external
> references   ");
>    //---------------------------------------------------------------------
> --------------------------
> diff -Naurw doxygen-1.4.3.orig/src/dot.cpp doxygen-1.4.3/src/dot.cpp
> --- doxygen-1.4.3.orig/src/dot.cpp	2005-04-17 17:55:56.000000000 +0100
> +++ doxygen-1.4.3/src/dot.cpp	2005-05-24 23:44:22.929947200 +0100
> @@ -29,6 +29,8 @@
>  #include "docparser.h"
>  #include "debug.h"
>  #include "pagedef.h"
> +#include "pre.h"
> +#include "bufstr.h"
> 
>  #include <qdir.h>
>  #include <qfile.h>
> @@ -2714,6 +2716,24 @@
>  #endif
>    absOutFile+=outFile;
> 
> +  // Preprocess the file if needed */
> +  if(Config_getBool("PREPROCESS_DOT_FILES"))
> +  {
> +    BufStr ppBuf(512);
> +
> +    preprocessFile(inFile, ppBuf);
> +
> +    // Rewrite the buffer to the input file
> +    QFile file(inFile);
> +    if (!file.open(IO_WriteOnly))
> +    {
> +      err("Could not open file %s for writing\n",inFile);
> +    }
> +    file.writeBlock( ppBuf.data(), ppBuf.curPos() );
> +    file.close();
> +  }
> +
> +
>    // chdir to the output dir, so dot can find the font file.
>    QCString oldDir = convertToQCString(QDir::currentDirPath());
>    // go to the html output directory (i.e. path)
> 
> 
> 
> Cheers,
> 
> Mike

[Doxygen-develop] Documenting methods inherited from <base class> and others

[Janvier A. <ja...@gm...>]

Hi!

I am resubmitting my query since it has been more than a week now and I 
still got no answers.

I am new to doxygen and I like to use it document my projects. 
Currently, I am looking
for a way to produce a documentation similar to a section produced by 
javadoc. That section
is the "Methods inherited from class ...". Then under this section, it 
lists (with appropriate
links) the methods that the current class being documented inherited 
from its parent class.

Is there a way to do this in doxygen?

Is it also possible to list automatically a nested class?

Is it also possible to list all the classes that was derived from class 
that is currently
being documented?

Another program called cppdoc does this. Is there a way to emulate this 
in doxygen?

Thanks!

-- 
To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it.  - Scott Granneman, Security Focus

RE: [Doxygen-develop] Spell checking

[Michael M. <Mic...@tt...>]

Hi,

What I had in mind was using a DocVisitor to dump a file of the words (with
some file/line information) that should be spell checked.  This can then be
checked with something like aspell, perhaps using a small bit of script to
manage the error reporting etc...  Any other spelling tool could be used;
that's not for Doxygen to worry about :)

I think that this should not affect Doxygen very much at all, but has the
advantage of generating documents and spell checking in one step, while also
being sensitive to Doxygen mark-up, and as you say, removing symbols and the
like.

Cheers,

Mike

> -----Original Message-----
> From: dox...@li... [mailto:doxygen-develop-
> ad...@li...] On Behalf Of Stefan Kost
> Sent: 24 June 2005 12:53
> To: Michael McTernan
> Cc: dox...@li...
> Subject: Re: [Doxygen-develop] Spell checking
> 
> hi hi,
> aspell already has a c/c++ comment mode. One idea for improvment I have
> for that
> is to filter the wors against the TAGS database before spell-checking.
> This
> would get dis of all the warning regarding mispelled words which are in
> fact
> symbols (function names etc.).
> 
> Stefan
> 
> Michael McTernan wrote:
> > Hi there,
> >
> > I'm starting to build up a bit of documentation using Doxygen, and
> realise
> > that I've made the odd spelling mistake.  It would help me if Doxygen
> would
> > check spellings while generating documentations and produce warnings.
> >
> > Checking the lists archives, I haven't found anything significant about
> > spell checking in Doxygen.  Surely this has been considered before?
> >
> > I was thinking that it would be simple to make a DocVisitor that
> together
> > with something like GNU aspell, could check all the observable text and
> > produce warnings for misspelt words.
> >
> > Particularly this would be better than extracting the comments from the
> > source, and then running a spell checker as things like \a words or
> \code
> > blocks could automatically be skipped.
> >
> > Anyone have any comments on this?  If I made such a DocVisitor, would it
> be
> > welcomed?
> >
> > Cheers,
> >
> > Mike
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Doxygen-develop mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> >
> 
> --
>       \|/            Stefan Kost
>      <@ @>           private            business
> +-oOO-(_)-OOo------------------------------------------------------ - - -
> -   -
> |       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach
> 301166
> |      ///           04277 Leipzig      04251 Leipzig
> | __  ///            Germany            Germany
> | \\\///    Phone    +49341 2253538     +49341 30766101
> |  \__/     EMail    st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de
> |           WWW      www.sonicpulse.de  www.imn.htwk-
> leipzig.de/~kost/about.html
> ===-=-=--=---=---------------------------------- - - -  -    -

Re: [Doxygen-develop] Spell checking

[Stefan K. <ko...@im...>]

hi hi,
aspell already has a c/c++ comment mode. One idea for improvment I have for that
is to filter the wors against the TAGS database before spell-checking. This
would get dis of all the warning regarding mispelled words which are in fact
symbols (function names etc.).

Stefan

Michael McTernan wrote:
> Hi there,
> 
> I'm starting to build up a bit of documentation using Doxygen, and realise
> that I've made the odd spelling mistake.  It would help me if Doxygen would
> check spellings while generating documentations and produce warnings.
> 
> Checking the lists archives, I haven't found anything significant about
> spell checking in Doxygen.  Surely this has been considered before?
> 
> I was thinking that it would be simple to make a DocVisitor that together
> with something like GNU aspell, could check all the observable text and
> produce warnings for misspelt words.
> 
> Particularly this would be better than extracting the comments from the
> source, and then running a spell checker as things like \a words or \code
> blocks could automatically be skipped.
> 
> Anyone have any comments on this?  If I made such a DocVisitor, would it be
> welcomed?
> 
> Cheers,
> 
> Mike
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> 

-- 
      \|/            Stefan Kost
     <@ @>           private            business
+-oOO-(_)-OOo------------------------------------------------------ - - -  -   -
|       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach 301166
|      ///           04277 Leipzig      04251 Leipzig
| __  ///            Germany            Germany
| \\\///    Phone    +49341 2253538     +49341 30766101
|  \__/     EMail    st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de
|           WWW      www.sonicpulse.de  www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -