GNOME Bugzilla – Bug 671023
Numbered/bulleted lists not nested correctly in HTML output.
Last modified: 2012-07-09 17:49:54 UTC
Created attachment 208655 [details] Doxygen input producing incorrectly nested lists. As of 1.8.0, numbered/bulleted lists are not generated correctly in HTML output. All items beyond the first are nested an extra level deep. For example, the following input: ==== BEGIN EXAMPLE ==== /** @mainpage Lists A bulleted list: - First - Second - Third A numbered list: -# First -# Second -# Third */ ==== END EXAMPLE ==== Produces the following HTML output: ==== BEGIN EXAMPLE ==== <div class="contents"> <div class="textblock"><p>A bulleted list:</p> <ul> <li>First<ul> <li>Second</li> <li>Third</li> </ul> </li> </ul> <p>A numbered list:</p> <ol type="1"> <li>First<ol type="a"> <li>Second</li> <li>Third </li> </ol> </li> </ol> </div></div> ==== END EXAMPLE ==== Which renders something like this: ==== BEGIN EXAMPLE ==== A bulleted list: * First o Second o Third A numbered list: 1. First a. Second b. Third ==== END EXAMPLE ==== The expected output is the same level of nesting for every list item. This behavior was not present in 1.7.6, or any prior versions that I can recall. Build from 1.8.0 source package downloaded from web site, Ubuntu 11.10. Input attached. Doxyfile is the default generated by "doxygen -s -g".
Temporary wrkaround is to indent the first item by an extra space in the input: - First - Second - Third J
It seems like an issue with doctokenizer.l. When I added the following debug output: ==== BEGIN DIFF ==== --- doctokenizer.l.svn 2012-02-29 12:45:09.011335902 -0500 +++ doctokenizer.l 2012-02-29 12:42:39.611343878 -0500 @@ -427,6 +427,7 @@ int dashPos = text.findRev('-'); g_token->isEnumList = text.at(dashPos+1)=='#'; g_token->indent = computeIndent(yytext,dashPos); + fprintf(stderr, "TK_LISTITEM1 indent=%i text=\"%s\" yytext=\"%s\"\n", (int)g_token->indent, (const char *)text, yytext); return TK_LISTITEM; } <St_Para>^{MLISTITEM} { /* list item */ @@ -465,6 +466,7 @@ int dashPos = text.findRev('-'); g_token->isEnumList = text.at(dashPos+1)=='#'; g_token->indent = computeIndent(text,dashPos); + fprintf(stderr, "TK_LISTITEM2 indent=%i text=\"%s\" yytext=\"%s\"\n", (int)g_token->indent, (const char *)text, yytext); return TK_LISTITEM; } <St_Para>{BLANK}*\n{MLISTITEM} { /* list item on next line */ ==== END DIFF ==== And ran it against an input with a list of 5 items (marked with " -", 4 spaces then a hyphen), and I saw this output: ==== BEGIN OUTPUT ==== TK_LISTITEM1 indent=3 text=" - " doctokenizerYYtext=" - " TK_LISTITEM2 indent=4 text=" - " doctokenizerYYtext=" - " TK_LISTITEM2 indent=4 text=" - " doctokenizerYYtext=" - " TK_LISTITEM2 indent=4 text=" - " doctokenizerYYtext=" - " TK_LISTITEM2 indent=4 text=" - " doctokenizerYYtext=" - " ==== END OUTPUT ==== Note that yytext is missing the first whitespace of the first item, I guess it was consumed elsewhere. I see, comparing the 1.8.0 source to 1.7.6, that a number of changes related to LISTITEM were made (most look like they relate to markdown support). I was unable to fix the problem, because I am not familiar enough with doxygen's grammar and with the changes that were made. I was, however, able to make it parse lists correctly by using the doctokenizer.l from 1.7.6 with the rest of the 1.8.0 source. Of course, I don't know what other side-effects this has, but it does seem to be generating *my* documentation correctly, so it's the solution I will use for now until there is a proper patch.
Happens if the list is found at the beginning of a new paragraph and at an indenting level > 0. Can you test if the following patch fixes the problem? --- doctokenizer.l.orig 2012-03-03 11:28:39.000000000 +0100 +++ doctokenizer.l 2012-03-03 11:28:52.000000000 +0100 @@ -684,7 +684,7 @@ } else // found end of a paragraph { - g_token->indent=computeIndent(yytext,(int)yyleng-1); + g_token->indent=computeIndent(yytext,(int)yyleng); int i; // put back the indentation (needed for list items) for (i=0;i<g_token->indent;i++)
Thanks. I applied your patch to the 1.8.0 source available from the tarball on the web site (have not tried the latest from SVN), and ran it against the file I'm about to attach, and the output looks correct. It seems to have fixed the problem.
Created attachment 208933 [details] Test input for Comment 4
*** Bug 671312 has been marked as a duplicate of this bug. ***
*** Bug 671710 has been marked as a duplicate of this bug. ***
Problem should be fixed in 1.8.1.1. Please reopen the bug report if you still see it.