a collection of bugs or at least problems

[aotto1968]

• [X] Problem: unable to add a @TO \b string into a `...` code section if a \c TO alias exists.
  • usage
• [ ] BUG \c verbatim with /// and no inline \verbatim
  • usage
  • needinfo
• [ ] BUG snippet in FRONT of \e block_id reference SAME page
  • needinfo
• [ ] BUG \page with string __parser__
  • bug
  • needinfo
• [ ] BUG @paragraph on @page

Describe the bug → a collection of bugs or at least problems

To Reproduce use the attachment: doxygen_bug__latest.tar.gz

version

doxygen -V 1.12.0 (14fc65f92184f8d788d5fb2723fb28e773dc4a5a) with sqlite3 3.42.0.

[albert-github]

The problem here is that we have a number of problems mentioned in 1 issue making it hard to answer and to classify. I added a small "tasklist" to the issue a bit of an overview.

• Problem: unable to add a @TO \b string into a `...` code section if a \c TO alias exists.

This is in my opinion usage, it is the way doxygen handles ALIASES and markdown code spans and especially the order of them. When having:

- test \` #1: `abc @TO xyz` → \b bug, \`...\` evalute \c alias ?
- test \` #2: `abc \@TO xyz` → \b bug
- test \` #3: `abc @@TO xyz` → \b bug
- test \` #1: `abc @noop xyz` → \b bug, \`...\` evalute \c alias ?
- test \` #2: `abc \@noop xyz` → \b bug
- test \` #3: `abc @@noop xyz` → \b bug
- test \` #1: <code>abc @TO xyz</code> → \b bug, \`...\` evalute \c alias ?
- test \` #2: <code>abc \@TO xyz</code> → \b bug
- test \` #3: <code>abc @@TO xyz</code> → \b bug
- test \` #1: <tt>abc @TO xyz</tt> → \b bug, \`...\` evalute \c alias ?
- test \` #2: <tt>abc \@TO xyz</tt> → \b bug
- test \` #3: <tt>abc @@TO xyz</tt> → \b bug

we get:

[albert-github]

• BUG \c verbatim with /// and no inline \verbatim

I think the relevant part of the issue:

- test \c verbatin \e inline → \b problem not \e inline (no bug):  \verbatim abc @TO xyz \endverbatim
- test \c verbatim after /// → \b bug : \ref dummy

Result:

• the \verbatim is a sectioning command and thus will not be inline as already noted (see also the documentation where it is stated: "\verbatim Starts a block of text that will be verbatim included in the documentation"
• the second bullet point about /// is in my opinion correct the /// are just normal characters as they are in a /** ... */ comment block.
  • did I miss something here?

[albert-github]

• BUG snippet in FRONT of \e block_id reference SAME page

Interesting case, is a corner case probably never thought about. The solution I see here is to use the doxygen snippet facility (\snippet). You probably will also need to the \noop command to make the block-ids invisible.

• Will this work for you?

[albert-github]

• BUG \page with string __parser__

I split the problem and have for this part:

/**

\mainpage bug

# BUG \\page with string \_\_parser\_\_

BUG: the format code is part of the heading → don't write a warning

\li \ref alc-parser


**/

some XXX dummy

// vim: syntax=doxygen

I don't see a warning.

• What warning do you mean?

[albert-github]

• BUG \page with string __parser__

The problem you see is probably in the page that is referenced by the link:

/**

\page alc-parser alc __parser__

**/

which results in:

This problem is, probably, analogous to the problem from #6925 where it was handled for sections by means of #7012 Looks like this is still a bug.

• is this what you meant?

[aotto1968]

ok, first I update to latest doxygen, just be

doxygen -v 1.13.0 (b75f8d594a78a986352bda81ce3b94d15d4f4aae)

• BUG \page with string __parser__

The problem you see is probably in the page that is referenced by the link:

/**

\page alc-parser alc __parser__

**/

which results in:

This problem is, probably, analogous to the problem from #6925 where it was handled for sections by means of #7012 Looks like this is still a bug.

• is this what you meant?

I'm not confirm with your examples because I don't see the "written-out-format-text",

• my problem is just that the <strong>... text was added to the heading and this is not what I want.

Two possible solutions :

1. make a warning and skip the <strong>... text,
2. make the <strong>.. text to a real strong → this should then also be done for all possible formatting.

[aotto1968]

• BUG snippet in FRONT of \e block_id reference SAME page

Interesting case, is a corner case probably never thought about. The solution I see here is to use the doxygen snippet facility (\snippet). You probably will also need to the \noop command to make the block-ids invisible.

• Will this work for you?

The @snippet is possible but not always because I use a lot of generated code the this code has no @snippet marker

[aotto1968]

• BUG \c verbatim with /// and no inline \verbatim

I think the relevant part of the issue:

- test \c verbatin \e inline → \b problem not \e inline (no bug):  \verbatim abc @TO xyz \endverbatim
- test \c verbatim after /// → \b bug : \ref dummy

Result:

• the \verbatim is a sectioning command and thus will not be inline as already noted (see also the documentation where it is stated: "\verbatim Starts a block of text that will be verbatim included in the documentation"

• the second bullet point about /// is in my opinion correct the /// are just normal characters as they are in a /** ... */ comment block.

  • did I miss something here?

you missed the point, because the example is test.h and this file has no /** ... **/ block.

/// \brief verbatim at test.h → \b bug, get ///
/// \verbatim
/// abc @TO xyz
/// \endverbatim
extern int dummy;

for /// abc @TO xyz the /// is the doxygen marker and abc @TO xyz is the test to be verbatim

[aotto1968]

The problem here is that we have a number of problems mentioned in 1 issue making it hard to answer and to classify. I added a small "tasklist" to the issue a bit of an overview.

• Problem: unable to add a @TO \b string into a ... code section if a \c TO alias exists.

This is in my opinion usage, it is the way doxygen handles ALIASES and markdown code spans and especially the order of them. When having:

- test \` #1: `abc @TO xyz` → \b bug, \`...\` evalute \c alias ?
- test \` #2: `abc \@TO xyz` → \b bug
- test \` #3: `abc @@TO xyz` → \b bug
- test \` #1: `abc @noop xyz` → \b bug, \`...\` evalute \c alias ?
- test \` #2: `abc \@noop xyz` → \b bug
- test \` #3: `abc @@noop xyz` → \b bug
- test \` #1: <code>abc @TO xyz</code> → \b bug, \`...\` evalute \c alias ?
- test \` #2: <code>abc \@TO xyz</code> → \b bug
- test \` #3: <code>abc @@TO xyz</code> → \b bug
- test \` #1: <tt>abc @TO xyz</tt> → \b bug, \`...\` evalute \c alias ?
- test \` #2: <tt>abc \@TO xyz</tt> → \b bug
- test \` #3: <tt>abc @@TO xyz</tt> → \b bug

we get:

My core problem is that I fought the `...` is something like a do nothing which is more like @verbatim but this is not the case,

• this was the reason why I tested the inline-verbatim which also doesn't exists.

[albert-github]

@aotto1968 seen the complexity, the misunderstandings, the overview, the classification etc. it is better to split the issue in 5 separate issues.

• can you create the 5 issues based on the original issue
• I will re-add my comment to the new issues
• you can re-add your responses to the new issues again.

[albert-github]

@aotto1968 do you plan plan to split the issue in sub issues as requested in https://github.com/doxygen/doxygen/issues/11060#issuecomment-2275162912

[jhasse]

I've extracted the \verbatime + /// issue.