Normal documentation unexpectedly rendered as code about docsforge HOT 4 CLOSED

It's related to markdown.

Docsforge uses MARKDOWN_SUPPORT = YES which is the same default as doxygen uses, and it's currently not exported.
I'll add exporting it to my todo list.

Alternative in the meantime:

Your code comments has over 4 spaces, and it's causing it. You can see your doxygen raw xml output at temporary url, look for <compoundname>breath::crc</compoundname>, followed by sibling node <detaileddescription>, inside it you'll find that all your code comment is inside <verbatim> which is doxygen's tag for code snippet.

I tried changing your code to only 1 space and it stops being rendered as code.

Change:

//!     This template is instantiated over a traits class which provides
//!     the characterizing parameters of the CRC. To the best of my
//!     knowledge, these parameters were first identified by Ross N.

etc...

To:

//! This template is instantiated over a traits class which provides
//! the characterizing parameters of the CRC. To the best of my
//! knowledge, these parameters were first identified by Ross N.

etc...

from docsforge.

Fixed in development server. Will be released in a few days.

Added MARKDOWN_SUPPORT option to docsforge.yaml

Please check in a a few days and report that it works, and I'll close this issue.

Note:

As far as I know, this is the only flag in doxygen's explanation that they state:

Disable only in case of backward compatibilities issues.

See link

from docsforge.

Yeah. All my documentation comments are like that, running from column 9 to column 72, or less. What perplexed me is that most of them looked right. Then I got what the issue is: if you write e.g.:

\somecommand ...
    text text

then "text text" is rendered as code, because it's more indented with respect to "\somecommand". I fixed the indentation of the command in all such cases and it's OK now. Unfortunately, you fixed the "issue" on your part before I could do any experiment and save you some work :-)

If I can suggest something, I'd let the user "include" his own doxygen.cfg from the docsforge.yaml file, at least when the latter comes from the repository. That would save the user himself from duplicating stuff between doxygen.cfg and docsforge.yaml, and would save you from duplicating Doxygen options in your own code (in the end, probably every options is used by someone, so, if DocsForge gains traction, you'll end up exporting all the commands at request of some user).

from docsforge.

No problem :) As you said, I would have added it anyway if not now then in the future.

Thanks for your suggestion,

I originally planned to simply duplicate the doxygen.cfg, however it was too error-prone in my tests.

The YES/NO fields were not, but string fields (like INPUT, ALIAS, etc) can depend on relative paths, and can depend on their cmake script if they use it to build their doxygen docs.

On a side note, the vast majority of projects using doxygen that I've seen, remain with the default cfg values, which are the same as what docsforge uses.

Closing issue, reopen if you still need MARKDOWN_SUPPORT:NO and it's not working as expected.

from docsforge.