doxygen-develop Mailing List for Doxygen (Page 30)
Brought to you by:
dimitri
Menu
▾
▴
doxygen-develop — List for discussing new features, submitting patches, etc.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(4) |
Jul
(29) |
Aug
(8) |
Sep
(8) |
Oct
(17) |
Nov
(34) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(20) |
Feb
(14) |
Mar
(11) |
Apr
(9) |
May
(8) |
Jun
(7) |
Jul
(25) |
Aug
(12) |
Sep
(12) |
Oct
(24) |
Nov
(27) |
Dec
(12) |
| 2003 |
Jan
(12) |
Feb
(14) |
Mar
(15) |
Apr
(11) |
May
(17) |
Jun
(20) |
Jul
(32) |
Aug
(13) |
Sep
(34) |
Oct
(12) |
Nov
(16) |
Dec
(33) |
| 2004 |
Jan
(20) |
Feb
(6) |
Mar
(20) |
Apr
(15) |
May
(16) |
Jun
(28) |
Jul
(7) |
Aug
(7) |
Sep
(17) |
Oct
(16) |
Nov
(17) |
Dec
(43) |
| 2005 |
Jan
(15) |
Feb
(5) |
Mar
(14) |
Apr
(4) |
May
(3) |
Jun
(8) |
Jul
(17) |
Aug
(16) |
Sep
(7) |
Oct
(17) |
Nov
(1) |
Dec
(7) |
| 2006 |
Jan
(7) |
Feb
(6) |
Mar
(10) |
Apr
(6) |
May
(3) |
Jun
(4) |
Jul
(3) |
Aug
(3) |
Sep
(18) |
Oct
(11) |
Nov
(10) |
Dec
(3) |
| 2007 |
Jan
(12) |
Feb
(12) |
Mar
(23) |
Apr
(5) |
May
(13) |
Jun
(6) |
Jul
(5) |
Aug
(4) |
Sep
(8) |
Oct
(10) |
Nov
(6) |
Dec
(7) |
| 2008 |
Jan
(7) |
Feb
(13) |
Mar
(35) |
Apr
(14) |
May
(13) |
Jun
(4) |
Jul
(9) |
Aug
(6) |
Sep
(12) |
Oct
(9) |
Nov
(6) |
Dec
(3) |
| 2009 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
(15) |
May
(1) |
Jun
(2) |
Jul
(7) |
Aug
(3) |
Sep
(4) |
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2010 |
Jan
(4) |
Feb
|
Mar
(5) |
Apr
(1) |
May
(5) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(11) |
Oct
(2) |
Nov
(1) |
Dec
(5) |
| 2011 |
Jan
(12) |
Feb
(3) |
Mar
(28) |
Apr
(4) |
May
(3) |
Jun
(4) |
Jul
(15) |
Aug
(12) |
Sep
(2) |
Oct
(3) |
Nov
(6) |
Dec
(3) |
| 2012 |
Jan
(1) |
Feb
(4) |
Mar
(9) |
Apr
(5) |
May
(6) |
Jun
(6) |
Jul
(3) |
Aug
(3) |
Sep
(4) |
Oct
(2) |
Nov
(9) |
Dec
(7) |
| 2013 |
Jan
(8) |
Feb
(14) |
Mar
(15) |
Apr
(21) |
May
(29) |
Jun
(34) |
Jul
(3) |
Aug
(7) |
Sep
(13) |
Oct
(1) |
Nov
(3) |
Dec
(5) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(2) |
Jun
(4) |
Jul
(2) |
Aug
(2) |
Sep
(4) |
Oct
(4) |
Nov
(4) |
Dec
(2) |
| 2015 |
Jan
(7) |
Feb
(4) |
Mar
(3) |
Apr
(15) |
May
(4) |
Jun
(9) |
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
(3) |
Dec
(7) |
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(5) |
| 2018 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
|
May
(7) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2021 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Greg T. <gre...@bl...> - 2007-04-04 15:54:45
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <p>Hi there.<br> </p> <p>I think it would be really cool to add the following functionality to doxygen at compile-time. As a warning, I have used doxygen but haven't messed with its source code, so apologies if what I propose is silly or unfeasible.<br> </p> <p>I believe some sort of modification to config.h would allow for generation of an MSVC .rules file similar to (but obviously huger than) than the following:<br> </p> <p><tt><?xml version="1.0" encoding="utf-8"?><br> <VisualStudioToolFile<br> Name="doxygen"<br> Version="8.00"<br> ><br> <Rules><br> <CustomBuildRule<br> Name="doxygen"<br> DisplayName="doxygen"<br> CommandLine="echo @INCLUDE = [inputs]&gt;$(IntDir)\$(InputName).temp&#x0D;&#x0A;[AllOptions]&#x0D;&#x0A;doxygen $(IntDir)\$(InputName).temp"<br> Outputs="$(OutDir)\html\index.html"<br> FileExtensions="*.doxygen"<br> ExecutionDescription="Generating doxygen documentation..."<br> ><br> <Properties><br> <StringProperty<br> Name="PROJECTNAME"<br> DisplayName="Project name"<br> Category="Project"<br> Description="The project name."<br> HelpURL=<a class="moz-txt-link-rfc2396E" href="http://www.stack.nl/~dimitri/doxygen/config.html#cfg_project_name">"http://www.stack.nl/~dimitri/doxygen/config.html#cfg_project_name"</a><br> Switch="echo PROJECT_NAME=[value]&gt;&gt;$(IntDir)\$(InputName).temp &amp;"<br> DefaultValue="$(ProjectName)"<br> /><br> <StringProperty<br> Name="OUTPUTDIRECTORY"<br> DisplayName="Output directory"<br> Category="Project"<br> Description="The output directory for generated documentation."<br> HelpURL=<a class="moz-txt-link-rfc2396E" href="http://www.stack.nl/~dimitri/doxygen/config.html#cfg_output_directory">"http://www.stack.nl/~dimitri/doxygen/config.html#cfg_output_directory"</a><br> Switch="echo OUTPUT_DIRECTORY=[value]&gt;&gt;$(IntDir)\$(InputName).temp &amp;"<br> DefaultValue="$(OutDir)"<br> /><br> <EnumProperty<br> Name="BRIEFMEMBERDESC"<br> DisplayName="Brief Member Desc"<br> Category="Project"<br> Description="Include brief member descriptions after the members."<br> HelpURL=<a class="moz-txt-link-rfc2396E" href="http://www.stack.nl/~dimitri/doxygen/config.html#cfg_brief_member_desc">"http://www.stack.nl/~dimitri/doxygen/config.html#cfg_brief_member_desc"</a> <br> DefaultValue="1"<br> ><br> <Values><br> <EnumValue<br> Value="0"<br> Switch="echo BRIEF_MEMBER_DESC=NO&gt;&gt;$(IntDir)\$(InputName).temp &amp;"<br> DisplayName="No"<br> /><br> <EnumValue<br> Value="1"<br> Switch="echo BRIEF_MEMBER_DESC=YES&gt;&gt;$(IntDir)\$(InputName).temp &amp;"<br> DisplayName="Yes"<br> /><br> </Values><br> </EnumProperty><br> </Properties><br> </CustomBuildRule><br> </Rules><br> </VisualStudioToolFile><br> </tt></p> <p>This would allow for .doxygen files to have their own configuration section in the project settings. Basically, the rule file generates a temporary doxygen file on the fly and then runs doxygen, all based on user-selected parameters in the project settings. I don't foresee this being terribly difficult to do. Another advantage is that it's portable - if you want to carry the project over to posix, just take the generated doxygen file and ignore the MSVC project file.<br> </p> <p>What do you think?<br> </p> <div class="moz-signature">-- <br> <p> Greg Toombs <br> Software consultant <br> <a href="http://www.mountainpath.ca" title="Mountain Path Consultation"> Mountain Path Consultation </a> <br> (519) 400-0065 <br> </p> </div> </body> </html> |
|
From: David L <id...@ho...> - 2007-03-30 21:25:40
|
>>I hacked up the doxygen source to add support for GLE. >>http://glx.sourceforge.net/ <snip> >From: "Klaus Otto" <Kla...@gm...> <snip> > IMHO this task would be a perfect job for the @cmd @endcmd >extension/patch >proposed some time ago in >http://sourceforge.net/mailarchive/message.php?msg_id=007701c66df8%24e4a1be00%245d161bac%40MM1laptop > >It works perfectly for me generating inlined Message sequence diagrams. > That sounds good to me. While I was doing my hack I thought that there should be a more general approach. Did that patch ever get integrated into Doxygen? If not, I would vote for it (or something like it). Thanks, David _________________________________________________________________ Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ |
|
From: Klaus O. <Kla...@gm...> - 2007-03-29 20:00:13
|
David, IMHO this task would be a perfect job for the @cmd @endcmd extension/patch proposed some time ago in http://sourceforge.net/mailarchive/message.php?msg_id=007701c66df8%24e4a1be00%245d161bac%40MM1laptop It works perfectly for me generating inlined Message sequence diagrams. Regards, Klaus -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail |
|
From: Brendon C. <bc...@av...> - 2007-03-29 04:50:06
|
Hi All,
I have just started working on a small patch for doxygen that attempts
to improve the matching of function parameters when used with templates.
In particular if I run doxygen over the following:
#include <set>
// Example in the global namespace.
class Blah1{};
void Function1(std::set<Blah1>&);
/** \fn Function1(std::set<Blah1, std::less<Blah1>,
std::allocator<Blah1> > &)
* \brief Some brief 1.
*
* A detail section 1.
*/
// Example inside a namespace called EDoc.
namespace EDoc
{
class Blah2{};
void Function2(std::set<Blah2>&);
}
/** \fn EDoc::Function2(std::set<EDoc::Blah2, std::less<EDoc::Blah2>,
std::allocator<EDoc::Blah2> > &)
* \brief Some brief 2.
*
* A detail section 2.
*/
It should successfully match the documentation provided by the \fn
blocks with the function declarations. These two identifiers are
actually identical, its just that one explicitly states the default
template parameters.
I need this functionality as i have a program that generates \fn
blocks that explicitly state the entire template. I have not yet found
a way of getting it to omit default template parameters. So i hope to
improve doxygen a little by allowing it to match such blocks. So far
with the exception of the bug mentioned below i think it have a
successful modification.
I have come across what seems like a bug in doxygen that is stopping
my patch from working in all situations.
In particular if you process the above with Doxygen 1.5.1 you will get
the following warnings:
/home/bcosta/dev/test/doxy.cpp:6: Warning: no matching file member
found for
Function1(std::set< Blah1, std::less< Blah1 >, std::allocator< Blah1 >
> &)
Possible candidates:
void Function1(std::set< Blah1 > &)
/home/bcosta/dev/test/doxy.cpp:18: Warning: no matching file member
found for
EDoc::Function2(std::set< EDoc::Blah2, std::less< EDoc::EDoc::Blah2 >,
std::allocator< EDoc::Blah2 > > &)
Possible candidates:
void Function2(std::set< Blah2 > &)
The first warning is as expected (And is not generated when using the
patch) but the second one shows the bug. Notice the
std::less<EDoc::EDoc::Blah2> Doxygen is for some reason incorrectly
giving the prefix of Bah2 as EDoc::EDoc:: not EDoc::
Would it be possible for someone to look into this? I am not at all
familiar with Doxygens parsing and have no idea where this additional
EDoc:: layer could be coming from. Eithre that or if someone would be
willing to point me to the place in code where I can look further into
this problem i would greatly appreciate it.
Thanks,
Brendon.
|
|
From: Brendon C. <br...@ch...> - 2007-03-27 22:48:54
|
Thanks for the info. In my situation the order of the documentation is not overly important. With that said i would prefer it to take the order to be such that the first documentation block encountered would be first in the detailed section. This way if two documentation blocs are in the same file it is easy to determine which goes first, and if you want to do it between files well then it is important how you construct the INPUT file list for the files to be scanned. I just created a small patch to entry.cpp in the doxygen-1.5.1 source which will append the detailed documentation from a new entry that is being added to an existing entry if the two entries have the same name. Thinking about it more it may be better for the entry to be added as it is currently, but to modify the place in the doxygen source that makes use of this list to generate the documentation. The m_sublist QList contains the duplicates from my example, it just seems that whatever it is that generates the documentation from this list only uses the first item it finds of a given name and ignores the second. If this does not work out, ill give the /copydoc command a try. Thanks, Brendon. Dave Dodge wrote: > On Mon, Mar 26, 2007 at 09:18:33PM +1000, Brendon Costa wrote: >> I would like to be able to perform a union of this documentation so that >> if you look at the documentation for MyFunction you will see something like: >> >> Brief for function. >> >> Detail 1 for function. >> Detail 2 for function. > > One thing to bear in mind is how you would tell Doxygen which detail > should come first in the unioned version. > >> Is there anything that can achieve this currently? > > Not trivially, I think. > >> Basically i have additional documentation for every function that is >> automatically generated by an external program that i want to >> include in addition to the user defined documentation. > > I haven't tried this, but you might be able to use \copydoc. For > example have your generated documentation use slightly modified > function names so that Doxygen thinks the documentation is for some > other function, and then use \copydoc to bring that into the function > that it's really meant to be with. I don't know if you can then stop > Doxygen from outputting the fake function in the final documentation, > though. > > In the few cases where I need to programmatically generate the input > to Doxygen, I actually pre-process the code file itself. For example > for one set of functions I have m4 macros to produce LaTeX pictures > which would be very tedious to type out and maintain by hand. The > original code is in "foo.h.m4", and the Makefile automatically > generates "foo.h" from that as part of the build. It's ugly, but it > does work. > > -Dave Dodge > > > > |
|
From: Dave D. <do...@do...> - 2007-03-27 18:01:17
|
On Mon, Mar 26, 2007 at 09:18:33PM +1000, Brendon Costa wrote:
> I would like to be able to perform a union of this documentation so that
> if you look at the documentation for MyFunction you will see something like:
>
> Brief for function.
>
> Detail 1 for function.
> Detail 2 for function.
One thing to bear in mind is how you would tell Doxygen which detail
should come first in the unioned version.
> Is there anything that can achieve this currently?
Not trivially, I think.
> Basically i have additional documentation for every function that is
> automatically generated by an external program that i want to
> include in addition to the user defined documentation.
I haven't tried this, but you might be able to use \copydoc. For
example have your generated documentation use slightly modified
function names so that Doxygen thinks the documentation is for some
other function, and then use \copydoc to bring that into the function
that it's really meant to be with. I don't know if you can then stop
Doxygen from outputting the fake function in the final documentation,
though.
In the few cases where I need to programmatically generate the input
to Doxygen, I actually pre-process the code file itself. For example
for one set of functions I have m4 macros to produce LaTeX pictures
which would be very tedious to type out and maintain by hand. The
original code is in "foo.h.m4", and the Makefile automatically
generates "foo.h" from that as part of the build. It's ugly, but it
does work.
-Dave Dodge
|
|
From: Brendon C. <br...@ch...> - 2007-03-26 11:18:41
|
If i use doxygen to generate documentation from the following code, it
does not perform a "union" of the two sets of documentation for the one
function and it also does not emit any warnings. It just uses the
documentation from the first block and ignores the second.
/** \brief Brief for function.
*
* Detail 1 for function.
*/
void MyFunction()
{
}
/** \fn MyFunction()
* Detail 2 for function.
*/
I would have expected a union of the two blocks to have been achieved
where possible, otherwise at least a warning to have been emitted
indicating that the documentation from the second block is being discarded.
I would like to be able to perform a union of this documentation so that
if you look at the documentation for MyFunction you will see something like:
Brief for function.
Detail 1 for function.
Detail 2 for function.
Is there anything that can achieve this currently? Basically i have
additional documentation for every function that is automatically
generated by an external program that i want to include in addition to
the user defined documentation.
Is there anything existing in doxygen that will achieve this and if not
would anyone mind me trying to add something like this that works either
with the above \fn command or a new command specifically for that purpose?
Thanks,
Brendon.
|
|
From: Brendon C. <br...@ch...> - 2007-03-24 03:37:32
|
Seems that the const location does not seem to be a problem with the most recent doxygen. Sorry about the previous email. I thought i had checked this before but i must have been using an earlier version. Thanks, Brendon. |
|
From: Brendon C. <br...@ch...> - 2007-03-23 21:06:50
|
Hi All, I wrote a mail to this list a while ago describing a feature that I would find very helpful in doxygen. I am willing to make the modifications myself, however I dont know where to start looking in the doxygen source base. Basically i need to modify code that matches function names. I.e. I want to update doxygen so that when processing it will consider the following two function names to be the same: Function(struct sockaddr const*) Function(const sockaddr*) That is just an example but the ordering of constness (In that example) and a few other things like whether the user defines a "struct" keyword make little difference. These still reference the same function. I need this for a program i have written that will generate comments that can be parsed by doxygen. The problem is that it generates in a sort of "canonical" format, not necessarily the format that the user used in the source, so doxygen fails to find functions referenced etc. So could someone point me in the correct direction in the doxygen source as to where i should be looking to modify this "matching" code? By the way would the community be fine with including a patch that does this? From my understanding it should have no effect on any existing doxygen projects. Thanks, Brendon. Brendon Costa wrote: > Hi All, > > (Feature request is at end of email if you are not interested in the > reason why I request it). > > > For a while I have been writing a tool that will allow C++ developers > to generate documentation with a comprehensive list of exceptions that > may propagate from any function. It does a number of other exception > checks that check for dangerous/erroneous usage of exceptions. > > Relevant to doxygen though, I am trying to get it to generate a file > that can be processed by doxygen as a standard source file in order to > add exception documentation to a functions doxygen documentation. > > > It will currently generate a file with documentation for all functions > that can throw exceptions in a format like: > > /*! \fn Func(std::ostream&, addrinfo const*) > * > * Throws Exceptions: > * - SysSocketException > * - Originating from: GetAddress(sockaddr const*) > * - E: OtherFunction(std::ostream&) > * . > * . > * > * . > */ > > This file would be included by the doxygen parser along with all other > source files and add the exception information to the functions > existing documentation. > > The amount of information generated is configurable, but as an example > the above displays that the function: Func(std::ostream&, addrinfo > const*) can throw a single exception of type: SysSocketException which > was originally thrown in a function called GetAddress(). > > The E: OtherFunction() line is currently optional and tells the user > that Func() makes a call to OtherFunction() which is the place where > the exception may enter Func(). This allows users to identify where in > the current function an exception will come from. > > Now the problem is that I have a standard way of representing > constness for function parameters. For example: > GetAddress(sockaddr const*) > > where in doxygen it is expecting whatever the user specified in the > source file (Which can from what I understand may differ in terms of > textual content but not semantics between the definition and > implementation). So doxygen will fail to automatically create a link > for a lot of my functions. > > This becomes even more of a problem when as in the above example the > function to which the documentation will belong is not identified so > the \fn command is unable to find the function which this > documentation block should belong. > > > --- Feature Request -- > > Anyhow, as a feature request is it possible to request that doxygen be > updated to recognise function parameters like: "sockaddr const*" to be > the same as: "const sockaddr*"? > > This feature could possibly be achieved with some simple text pattern > matching. I would also request that it match regardless of whether the > "struct" keyword is in the text also. > > > Thanks, > Brendon. > > > > |
|
From: David L <id...@ho...> - 2007-03-22 16:56:19
|
I hacked up the doxygen source to add support for GLE. http://glx.sourceforge.net/ (there is an examples link on that site that shows some of the functionality of GLE... some of it might be very useful for code documenation and compiments the functionality provide by graphviz I think). I don't know my way around the doxygen code base, so my changes are ugly and likely non portable, but I suspect somebody that knows what they're doing could fix it up pretty quickly (although they could probably do it from scratch pretty quickly too). Anyway, is there interest in adding this to the stock doxygen code base? Basically, I copied dot.cpp to gle.cpp and replaced dot with gle in that file with a few exceptions relating to config setting which I didn't make independent of DOT configuration. I also make a few changes to work around differences in the dot versus gle syntax. Then I more or less blindly copied a bunch of code in other files that related to DOT and made a GLE equivalent. It works on my Linux system, but one of my workarounds for gle behavior is probably not portable. Is there interest in my submitting what I've done? If so, where/how? Thanks... David _________________________________________________________________ Exercise your brain! Try Flexicon. http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglinemarch07 |
|
From: Matthew W. <mw_...@us...> - 2007-03-15 18:40:25
|
Matthew Woehlke wrote: > Dimitri van Heesch wrote: >> On 3/7/07, Matthew Woehlke wrote: >>> Is this a bug? >>> >>> "\c \e foo bar" == "<tt><i>foo</i> bar</tt>" >>> >>> Shouldn't it be: >>> >>> "<tt><i>foo</i></tt> bar"? >> That would indeed be more logical. >> >>> ...and any pointers where I can go tweak to fix it? >> src/docparser.cpp is where the commands are handled, in particular >> look at defaultHandleToken() and handleStyleArgument() > > Thanks. Oh, and I saw your reply to Tim, I'll go file a Real Bug Report > now... hopefully I can get a patch in a few days too. I'm still on 1.4.7 > because I want to use the @li2 I wrote. (Btw, what ever happened with > that patch I sent?) Here's a patch; I think it qualifies as "an ugly hack" :-). I added this to http://bugzilla.gnome.org/show_bug.cgi?id=418615 as well, but it would be great if other doxygen hackers could take a look. Be sure to add RetVal_Nested to doctokenizer.h also (yeah, I'm lazy, diff -r would have pulled in all my other changes also so I left out the one-liner). Thanks again for the pointer, Dimitri, you were spot-on! I also touched handleCommand as well although I'm not sure that is necessary. -- Matthew Caution: keep out of reach of adults. |
|
From: Matthew W. <mw_...@us...> - 2007-03-15 15:35:40
|
Dimitri van Heesch wrote: > On 3/7/07, Matthew Woehlke wrote: >> Is this a bug? >> >> "\c \e foo bar" == "<tt><i>foo</i> bar</tt>" >> >> Shouldn't it be: >> >> "<tt><i>foo</i></tt> bar"? > > That would indeed be more logical. > >> ...and any pointers where I can go tweak to fix it? > > src/docparser.cpp is where the commands are handled, in particular > look at defaultHandleToken() and handleStyleArgument() Thanks. Oh, and I saw your reply to Tim, I'll go file a Real Bug Report now... hopefully I can get a patch in a few days too. I'm still on 1.4.7 because I want to use the @li2 I wrote. (Btw, what ever happened with that patch I sent?) -- Matthew Caution: keep out of reach of adults. |
|
From: Dimitri v. H. <do...@gm...> - 2007-03-15 12:12:20
|
Hi Tim, I'll include your fix. Thanks! Next time please report issues in the bug tracker, not on the mailing list. Regards, Dimitri On 2/13/07, Tim Mensch <tim...@bi...> wrote: > > Hi all, > > There's been a bug in doxygen for several years now, and I'm hoping to get > it patched in the main code. I actually first mentioned this bug on the list > in 2003, but failed to actually bring it up as a change that needs to be > made: Doxygen looks for an &tm; for the trademark symbol, where the actual > (HTML/XML) symbol should be ™. There are only two changes that need to > be made to fix this: > > docparser.cpp, line 1313: > else if (symName=="&tm;") return DocSymbol::Tm; > change to > else if (symName=="™") return DocSymbol::Tm; > htmldocvisitor.cpp, line 104: > case DocSymbol::Tm: m_t << "&tm;"; break; > change to > case DocSymbol::Tm: m_t << "™"; break; > > &tm; doesn't do anything in Firefox at least. If someone needs backwards > compatibility with &tm; then the first change is to insert the line with > ™ instead of replacing the other line. > > Tim > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Doxygen-develop mailing list > Dox...@li... > https://lists.sourceforge.net/lists/listinfo/doxygen-develop > > |
|
From: Dimitri v. H. <do...@gm...> - 2007-03-15 10:58:05
|
On 3/7/07, Matthew Woehlke <mw_...@us...> wrote: > > Is this a bug? > > "\c \e foo bar" == "<tt><i>foo</i> bar</tt>" > > Shouldn't it be: > > "<tt><i>foo</i></tt> bar"? That would indeed be more logical. ...and any pointers where I can go tweak to fix it? src/docparser.cpp is where the commands are handled, in particular look at defaultHandleToken() and handleStyleArgument() Regards, Dimitri |
|
From: Arnold.Steve <arn...@en...> - 2007-03-12 15:40:24
|
Howdy: I was recently having a couple of ideas on this topic, at least the beginnn= ings of an Ada parser, and possibly extensible to Fortran as well. Anyway, the first level parser idea follows the suggested Doxygen route of = translating to something C/C++ish, while a second-level Ada parser should b= e achievable with GNAT/ASIS (as long as the code compiles with GNAT). I'm in the process of testing the first option (after I finish grading exam= s) using this sourceforge project: http://adatoccpptranslator.free.fr/ It appears to be last updated in 2005, but it may be worth maintaining if i= t produces reasonable output. Feel free to give it a try, otherwise I'll p= ost back some samples shortly. Have fun, Steve -----Original Message----- From: dox...@li... on behalf of Jeffrey Cr= eem Sent: Thu 3/1/2007 4:08 PM To: dox...@li... Cc:=09 Subject: Re: [Doxygen-develop] Fortran90 parser: interest? Arnold.Steve wrote: > I could use Fortran support in general, as well as Ada83/95... > > So yes, I'd day there's definitely interest. > > Steve > > -- > Stephen L. Arnold >=20=20 >=20=20=20 I agree. fortran support would be good. Ada 95/2005 support would be even b= etter. The information contained in this email message is intended only for the us= e of the individuals to whom it is addressed and may contain information th= at is privileged and sensitive. If the reader of this message is not the in= tended recipient, you are hereby notified that any dissemination, distribut= ion or copying of this communication is strictly prohibited. If you have re= ceived this communication in error, please notify the sender immediately by= email at the above referenced address. Thank you. |
|
From: <Eck...@t-...> - 2007-03-11 17:52:48
|
Hello Everybody. Since today a new release of moritz the nassi-shneiderman generator for doxygen is available under https://sourceforge.net/projects/moritz/. This new release of moritz is able to generate dot-files for creating image-files (with dot-versions that are newer than mid-November 2003). A new help-argument to provide online information is available now. Nested switches without {} around the inner switch will be handled better now. The documentation of writing terminal-scripts (windows-batches or linux-scripts) is more detailed now. The linux-version is still missing but coming soon. Please try it out and use the forum on the sourceforge-side of moritz to ask question or to post comments. I think the next steps are: * debugging * programming a gui-wizard * writing a tutorial. If you have questions or suggestions please don't hesitate to post them in the forum under: https://sourceforge.net/forum/?group_id=167738 Kind Regards, Eckard Klotz |
|
From: Sebastian P. <web...@ha...> - 2007-03-08 19:28:48
|
Kevin McBride wrote: > Summary: The Technical Library Template Interface is a library capable > of providing standardized interfaces in Creative Commons EAL-4 standards > to the open source community. > > License: GNU Library General Public License (LGPL) > > Supported Platforms: *nix (Linux and most Unix-based) > > Programming Languages: C, C++, GNU Assembler ------------------------------------------------------------- I changed the description to your summary suggestion. Click here: http://www.stack.nl/~dimitri/doxygen/projects.html#libteklti Sebastian |
|
From: Matthew W. <mw_...@us...> - 2007-03-06 23:09:39
|
Is this a bug? "\c \e foo bar" == "<tt><i>foo</i> bar</tt>" Shouldn't it be: "<tt><i>foo</i></tt> bar"? ...and any pointers where I can go tweak to fix it? -- Matthew "Do you do windows as well?" "Only when I'm forced to deal with Microsoft..." -- from a story by Feech |
|
From: Matthew W. <mw_...@us...> - 2007-03-06 22:50:08
|
Matthew Woehlke wrote: > I would like to modify doxygen to not add space between formatted words > and trailing punctuation, e.g. I would like "if you set @c foo , don't > set @p bar ." to be equivalent to "if you set <c>foo</c>, don't set > <c>bar</c>.". Any tips where I would need to go digging to do this? (Or > is there a way to do it already?) Oh, I see, this works: "if you set @c foo, don't set @p bar." ...in which case my highlighter is broken and I will fix it. In case I don't find it before someone knowledgeable tells me, where is the logic that does this? (I am looking for the complete list of what punctuation is not included in parameter names, especially since it looks like ',' is handled differently depending on the command.) -- Matthew "Do you do windows as well?" "Only when I'm forced to deal with Microsoft..." -- from a story by Feech |
|
From: Matthew W. <mw_...@us...> - 2007-03-06 22:45:15
|
I would like to modify doxygen to not add space between formatted words and trailing punctuation, e.g. I would like "if you set @c foo , don't set @p bar ." to be equivalent to "if you set <c>foo</c>, don't set <c>bar</c>.". Any tips where I would need to go digging to do this? (Or is there a way to do it already?) -- Matthew "Do you do windows as well?" "Only when I'm forced to deal with Microsoft..." -- from a story by Feech |
|
From: Jeffrey C. <je...@th...> - 2007-03-02 00:08:34
|
Arnold.Steve wrote: > I could use Fortran support in general, as well as Ada83/95... > > So yes, I'd day there's definitely interest. > > Steve > > -- > Stephen L. Arnold > > I agree. fortran support would be good. Ada 95/2005 support would be even better. |
|
From: Arnold.Steve <arn...@en...> - 2007-03-01 19:42:08
|
I could use Fortran support in general, as well as Ada83/95... So yes, I'd day there's definitely interest. Steve -- Stephen L. Arnold =20 > -----Original Message----- > From: dox...@li...=20 > [mailto:dox...@li...] On=20 > Behalf Of A.Visser > Sent: Thursday, March 01, 2007 1:48 AM > To: dox...@li... > Subject: [Doxygen-develop] Fortran90 parser: interest? >=20 > Hi! >=20 > Last year, I've written together with Oleg Batrashev a Fortran90 > (subset) parser for Doxygen. Is there any interest to include=20 > the work? >=20 > Greetings, > Anke Visser >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the=20 > chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV > _______________________________________________ > Doxygen-develop mailing list > Dox...@li... > https://lists.sourceforge.net/lists/listinfo/doxygen-develop >=20 The information contained in this email message is intended only for the us= e of the individuals to whom it is addressed and may contain information th= at is privileged and sensitive. If the reader of this message is not the in= tended recipient, you are hereby notified that any dissemination, distribut= ion or copying of this communication is strictly prohibited. If you have re= ceived this communication in error, please notify the sender immediately by= email at the above referenced address. Thank you. |
|
From: Erik Z. <ze...@ma...> - 2007-03-01 18:22:47
|
On 3/1/07, A.Visser <A.V...@fz...> wrote: > Hi! > > Last year, I've written together with Oleg Batrashev a Fortran90 > (subset) parser for Doxygen. Is there any interest to include the work? > > Greetings, > Anke Visser Not as much as in the past, but definitely YES. Erik -- ************************************************* Erik Zeek ze...@ma... ************************************************* Against stupidity the very gods Themselves contend in vain. - Johann Christoph Friedrich von Schiller (1801) ************************************************* |
|
From: A.Visser <A.V...@fz...> - 2007-03-01 09:44:25
|
Hi! Last year, I've written together with Oleg Batrashev a Fortran90 (subset) parser for Doxygen. Is there any interest to include the work? Greetings, Anke Visser |
|
From: Kevin M. <ke...@pl...> - 2007-02-28 18:03:21
|
Sebastian Pipping wrote: > Kevin McBride wrote: > >>Please make sure that my project, libteklti >>[http://sourceforge.net/projects/libteklti] is added to the list. > > > ----------------------------------------------------------- > Sure. Please let me know what text you want > for the description. I think it should answer > these questions: > * sharp summary of function and problem domain > * license > * supported platforms > * programming language(s) used > Summary: The Technical Library Template Interface is a library capable of providing standardized interfaces in Creative Commons EAL-4 standards to the open source community. License: GNU Library General Public License (LGPL) Supported Platforms: *nix (Linux and most Unix-based) Programming Languages: C, C++, GNU Assembler > > > > Sebastian > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Doxygen-develop mailing list > Dox...@li... > https://lists.sourceforge.net/lists/listinfo/doxygen-develop > |
28 messages has been excluded from this view by a project administrator.
