GNOME Bugzilla – Bug 670805
List enumeration invalid
Last modified: 2018-07-30 10:39:17 UTC
Hi, there is a severe regression in v1.8.0 compared to 1.7.6: List items enumerated by numbers are replaced by multiple "1.", see attachment. Regards, ZenJu
Created attachment 208417 [details] Sample
This has to do with the way Markdown support works. To avoid it you can either set MARKDOWN_SUPPORT to NO, or remove the empty line between each list item. Let me know if this helps.
Wow, this was fast! >remove the empty line between each list item This is what I tried at first, but then the empty line is also missing in the generated html. Next I searched for something like "force empty line" to compensate for this, but couldn't find anything. >set MARKDOWN_SUPPORT to NO, This seems to solve this problem, after a rough overview the generated html now looks like it should. Thanks for the quick help! However wouldn't it be possible to "do the right thing" by default? I don't see any fundamental reason for converting a "2." or "3." at the beginning of a paragraph to a "1.". Would it be difficult to apply this mark-down only if there are at least two list items which start with a "1"? Likewise it doesn't make much sense to replace consecutive "3. 4. 5." by 1. 2. 3.".
You could end the item with a \n\n to get the empty line effect, but you are right about improving the robustness, so that what you want to do is just possible.
I'll make it such that a numbered list item can end with an empty line. Only if the next item has a lower number a new list will be started. So 1. item1 2. item2 3. item3 will create one list with numbers 1,2, and 3 as expected, whereas 1. item1 2. item2 1. item1 2. item2 1. item1 2. item2 will create 3 lists of 2 items each. When you want the visual effect in the output of an empty line after the item, you still need to use \n\n.
The fundamental problem with my example is, that it is prematurely interpreted as a list by the "mark down" algorithm. However I did not want to write a list, but to enter a number of steps, which shall be numbered exactly how I specified them, namely "1. 2. 3.". If this is automatically converted to "I. II. III." or if empty lines were interpreted as end of a list item, then this is not what I intended. I'm not sure if my usage can be integrated into a general logic - or if it should - I naturally would want it to, since I expect WYSIWYG by default, but I don't know the implication on other areas of Doxygen which may already depend on "empty lines marking the end of a list item". In case my usage should be supported by default, then allowing an item to end with an empty line will be not enough, but it must also be allowed to have empty lines in the middle of an item: 1. item1 Some Text 2. item2
If you don't want a list then you need the escape the dot, i.e 1\. first do this some test 2\. now do that Or use 1) and 2) instead.
I guess my usage pattern is best covered by disabling "MARKDOWN_SUPPORT". When it comes to lists I either use explicit numbers with potential empty lines between items, in which case I never want them replaced by multiple "1." or I use "-", "-#", which may be handled as lists. Without mark-down there is no risk of ending a list prematurely by accidentally inserting an empty line and it doesn't require special syntax to avoid unwanted replacement of numbers. I understand now that replacing "2. 6. 23." by "1. 2. 3." and ending lists by empty lines is actually a feature of mark-down and not a bug. While it seems this feature creates more problems than it solves, I am totally fine as long as mark-down is optional in Doxygen.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.8.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.
Created attachment 214441 [details] doxygen 1.8.1 update
Hi, 1. the numbering is now correct in 1.8.1 even if markdown is enabled and there are empty lines within a list. But the empty lines are removed from the final html, so that it still looks better with markdown disabled. See the screenshot with the new version v1.8.1 2. Empty lines in "verbatim" are now removed completely, see screenshot bottom right. This has been working correctly until 1.8.0. Regards, ZenJu
Can you please attach a self-contained example (source + config file in a tar or zip) that demonstrates the problems that are visible in the screenshot?
Sure, download "zenXml_v1.5.zip" from: http://sourceforge.net/projects/zenxml/files/v1.5/ Then open doxygen configuration file called "Doxyfile".
> 2. Empty lines in "verbatim" are now removed completely, To be more precise, not only empty lines, but even newlines are removed, so that it all ends on a single line as shown.
Hi ZenJu, I tried doxygen 1.8.1 on the example, and it looked ok. The verbatim section was nicely split over multiple lines. That said, earlier today while I had already uploaded the 1.8.1 release, I found a last minute bug that resulted in exactly the problem you see, so it could be that: 1) you have downloaded this faulty version, before the official one was uploaded and announced. 2) there was something wrong with uploading, causing the faulty version still being available instead of the fixed one. Can you have a look in the generated doxygen.css and tell me if you see the following section? pre.fragment { border: 1px solid #C4CFE5; background-color: #FBFCFD; padding: 4px 6px; margin: 4px 8px 4px 2px; overflow: auto; word-wrap: break-word; font-size: 9pt; line-height: 125%; font-family: monospace, fixed; font-size: 105%; } Can you tell me which version of doxygen you downloaded (source or binary, and if binary which one)?
>faulty version Indeed, this seems to have been the problem! I downloaded 1.8.1 again and things are improving. I've uploaded a comparison of generated html pages 1.8.0 1.8.1 - first release 1.8.1 - later release -> Comparison 1.8.0 vs 1.8.1.rar > tell me if you see the following section? It's missing from 1.8.1 first release, but available in 1.8.0 and 1.8.1 later release. When comparing 1.8.0 vs 1.8.1 later release the following regressions are remaining: 1. empty lines are missing in C++ sample code -> empty lines missing.PNG 2. The "files" tab is missing in the 1.8.1 html file -> Files Missing.PNG 3. The black bar left to \author is missing in 1.8.1 - not sure if this is a bug or by design. 4. The font size of \verbatim is increased in 1.8.1 compared to 1.8.0. Looks a little strange since the font size of regular C++ code did not change. Not sure if this is a bug, but it's not a big deal.
Created attachment 214456 [details] Comparison 1.8.0 vs 1.8.1
Created attachment 214457 [details] empty lines missing
Created attachment 214458 [details] Files Missing
As discussed in https://github.com/doxygen/doxygen/pull/734 , Doxygen has moved its issue tracking to https://github.com/doxygen/doxygen/issues All Doxygen tickets in GNOME Bugzilla have been migrated to Github. You can subscribe and participate in the new ticket in Github. You can find the corresponding Github ticket by searching for its Bugzilla ID (number) in Github. Hence I am closing this GNOME Bugzilla ticket. Please use the corresponding ticket in Github instead. Thanks a lot!