After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 665313 - Whitespace in front of "@if" removed differently in 1.7.x than 1.6.x
Whitespace in front of "@if" removed differently in 1.7.x than 1.6.x
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: general
unspecified
Other Mac OS
: Normal critical
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2011-12-01 18:03 UTC by MikeH
Modified: 2012-11-18 11:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description MikeH 2011-12-01 18:03:22 UTC
I have a lot of documentation done using 1.6.3.  In attempting to upgrade to 1.7.x, I discovered that both 1.7.3 and 1.7.5 handle whitespace around conditional @if statements and @endif statements differently.  The difference can be illustrated by writing text like the following:

   some text in front @if clike middle@endif tail text

1.7.5 eats the space before @if and after @endif, mangling the output and producing the following in the formatted output:

  some text in frontmiddletail text

Among the consequences is that if "middle" contained a reference to an object like a class name, the result won't be hyperlinked (because it's mangled and Doxygen itself fails to recognize it).  Here is an example of where it causes problems.  Suppose your code has this comment:

  /** 
   * Blah blah blah.
   *
   * Use the method @if java Compartment::setId(String id)@else setId()@endif. 
   */

The result in the formatted output will be:

  Blah blah blah.

  Use the methodsetId().

Doxygen 1.6.3 does not behave this way, and leaves the spaces in the final output.  I cannot find this change listed in the ChangeLog. I also don't know how to work around this behavior.

If I'm missing something obvious, or an explanation or a workaround, I apologize, and would appreciate it if someone could explain it to me.

Thanks.  BTW, Doxygen has been just a fantastic tool for us.  We use it to produce the documentation for our open-source library, libSBML.
Comment 1 Dimitri van Heesch 2011-12-10 12:19:46 UTC
This change was made to fix bug #620924. For inline @if..@endif constructs like in your example this doesn't work. I'll come up with a better solution in the next release.
Comment 2 Dimitri van Heesch 2011-12-10 20:39:26 UTC
This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.7.6.1. Please verify if this is indeed the case. Reopen the
bug if you think it is not fixed and please include any additional information
that you think can be relevant.
Comment 3 MikeH 2011-12-15 02:05:21 UTC
Hi,

Thanks for such a prompt response to this.  I've switched to using 1.7.6.1, and have tested this situation, and it looks like one half of the problem is indeed solved: it doesn't eat the space in front of @if.  However, it's still eating the space after @endif.  I used the following input file to test it:

   * a @if cpp b @else c @endif d 
   * 
   * a @if cpp b@else c @endif d 
   * 
   * a@if cpp b @else c @endif d 
   * 
   * a @if cpp b @else c@endif d 
   * 
   * a @if notcpp b @else c @endif d 
   * 
   * a @if notcpp b@else c @endif d 
   * 
   * a@if notcpp b @else c @endif d 
   * 
   * a @if notcpp b @else c@endif d 

Then I ran Doxygen with ENABLED_SECTIONS containing "cpp".  The result in the formatted output was:

a bd

a bd

abd

a bd

a cd

a cd

acd

a cd

From this, it appears that the whitespace after @endif is being removed.  This is still a bit problematic when the construct is used inside a paragraph.

Thank you very much for your help so far!

Best regards,
MH