New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List enumeration invalid (Origin: bugzilla #670805) #4582

Open
doxygen opened this Issue Jul 2, 2018 · 0 comments

Comments

Projects
None yet
1 participant
@doxygen
Owner

doxygen commented Jul 2, 2018

status NEW severity major in component general for ---
Reported in version 1.8.0 on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

On 2012-02-25 19:42:45 +0000, zhnmju123@gmx.de wrote:

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

On 2012-02-25 19:43:32 +0000, zhnmju123@gmx.de wrote:

Created attachment 208417
Sample

On 2012-02-25 19:46:15 +0000, Dimitri van Heesch wrote:

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.

On 2012-02-25 20:09:05 +0000, zhnmju123@gmx.de wrote:

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.".

On 2012-02-25 20:46:43 +0000, Dimitri van Heesch wrote:

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.

On 2012-02-26 18:24:38 +0000, Dimitri van Heesch wrote:

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.

On 2012-02-26 19:03:17 +0000, zhnmju123@gmx.de wrote:

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

On 2012-02-26 19:44:28 +0000, Dimitri van Heesch wrote:

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.

On 2012-02-26 23:01:39 +0000, zhnmju123@gmx.de wrote:

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.

On 2012-05-19 12:26:31 +0000, Dimitri van Heesch wrote:

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.

On 2012-05-19 13:23:01 +0000, zhnmju123@gmx.de wrote:

Created attachment 214441
doxygen 1.8.1 update

On 2012-05-19 13:23:16 +0000, zhnmju123@gmx.de wrote:

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

On 2012-05-19 13:30:17 +0000, Dimitri van Heesch wrote:

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?

On 2012-05-19 16:32:44 +0000, zhnmju123@gmx.de wrote:

Sure, download "zenXml_v1.5.zip" from:
http://sourceforge.net/projects/zenxml/files/v1.5/

Then open doxygen configuration file called "Doxyfile".

On 2012-05-19 16:34:21 +0000, zhnmju123@gmx.de wrote:

> 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.

On 2012-05-19 17:27:45 +0000, Dimitri van Heesch wrote:

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)?

On 2012-05-19 20:05:25 +0000, zhnmju123@gmx.de wrote:

>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.

On 2012-05-19 20:05:56 +0000, zhnmju123@gmx.de wrote:

Created attachment 214456
Comparison 1.8.0 vs 1.8.1

On 2012-05-19 20:06:14 +0000, zhnmju123@gmx.de wrote:

Created attachment 214457
empty lines missing

On 2012-05-19 20:06:27 +0000, zhnmju123@gmx.de wrote:

Created attachment 214458
Files Missing
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment