"Automatically correct list numbering when editing" - list's content blocks lead to inadequate list numbering autocorrection

[oleole39]

Hello,

Following issue report #35 (current issue reported using the modified plugin version you shipped in issue #35 if it matters) , here is another behavior likely to be unwanted as it is inconsistent with the preview panel.

In the edit panel, having a picture as a subpoint of a list ends the current list numbering (the list is autocorrected as below by the Automatically correct list numbering when editing" option)

1. first point
2. second point
    ![second point image](:/fad71f9cdf9547f1ba3437eab43d902c)
1. third point 

third point code blocks
```    

1. fourth point $$ \text{Test ratio} = \frac{\text{Test A}} {\text{Test B}} $$
2. fifth point Fifth point description text
3. sixth point
   1. first subpoint $$ \text{Test ratio} = \frac{\text{Test A}} {\text{Test B}} $$
   2. second subpoint second subpoint description text
   3. third subpoint
4. seventh point

   Whereas expected behavior would be:

5. first point
6. second point
7. third point

   third point code blocks

8. fourth point $$ \text{Test ratio} = \frac{\text{Test A}} {\text{Test B}} $$
9. fifth point Fifth point description text
10. sixth point
    1. first subpoint $$ \text{Test ratio} = \frac{\text{Test A}} {\text{Test B}} $$
    2. second subpoint second subpoint description text
    3. third subpoint
11. seventh point

    
    Expected behavior actually appears anyway in the preview panel, even if the first snippet above is to be found in the edit panel. 

I guess the same issue happens whatever block item is used inside a list (i tested only image, code block, katex element, and plain text).

An idea of a pattern mimicking the preview panel's behavior (I didn't check its code, that could be another interesting starting point) could be checking the content of the line preceding the current one and determine if is:

• a list bullet; then continue previous list numbering
• an empty line, or first line of the document; then start a new list numbering
• any indented text of level n-1 (will match plain text, picture tag, code block tag, etc.) that can be considered as list item's content since not separated from the list by an empty line; then continue to recursively test the preceding of the line being tested until running into one of the 2 other cases.

Edit: the preview panel actually interpret differently indentation depending on the content type:

• plain text not preceded by an empty line is interpreted as a list item's content by the preview panel, even if not indented. That would constitute a remaining minor inconsistency with preview panel if above pseudo code pattern is used. Even if I don't really understand the logic of this very behavior, but I guess this has to be discussed within Joplin's core project.
• other content blocks react correctly to indent hierarchy (tested with code blocks & katex).

[SeptemberHX]

It should be fixed now. Thanks for your feedback ! :)

com.septemberhx.Joplin.Enhancement.jpl.zip

[oleole39]

Thank you, I feel this is a kind of perfect fix!

Now a discrepancy remains between the behavior of Jopin Enhancement in the edit panel, and what is actually rendered in the preview panel, as mentioned in the first point of the edit section of my first message and shown in below sample (everything works as expected until the fourth point):

1. first point (list item alone)
2. second point (list item alone with block content)
    $$ \text{Test ratio} = \frac{\text{Test A}} {\text{Test B}} $$
3. third point (sublist items with various block content cases)
    1. first subpoint (katex case)
        $$ \text{Test ratio} = \frac{\text{Test A}} {\text{Test B}} $$
    2. second subpoint (code blocks case)
        ```txt
        second subpoint code blocks

3. third subpoint (picture case)
    ![third subpoint picture](:/fad71f9cdf9547f1ba3437eab43d902c)
4. fourth and final subpoint

4. fourth point (illustrating the problem) Additional NOT indented text at first level (I expect it to stop the current level of list numbering) Additional NOT indented text at first level (that does not increment any counter, which is OK) Additional indented text without number
   2. second subpoint (or first depending on how we expect it to be counted) Additional indented text without number,
      1. first subsubpoint
   3. fourth subpoint (or second depending on how we expect it to be counted)
5. fifth and final point

I can think only of a few straightforward alternatives for the list numbering autocorrection feature:

1. list numbering is to be stopped by two consecutive line breaks. a. First level only - this is the current default Joplin (or Markdown?) behavior in the preview panel (sublist levels are not autocorrected)
   b. All levels (would not seem convenient to me)
2. Base all autonumbering on indent (Joplin-Enhancement numbering autocorrection feature's behavior in the edit panel thanks to the current fix). As such, a list bullet followed by a line without a list number is considered as:
   • not a list item anymore if it has no indent.
   • a same-level bullet corresponding as per the indent, even if there is no bullet sign.

The second main alternative is what implements this fix which I perceive as the correct way to deal with all this. As I couldn't find a related issue on Joplin core's github tracker & forum I created a post in the forum linking to the current issue. I don't close the issue yet due to that.

There could be one more improvement to this fix - that a subpoint without a bullet is actually not counted in the numbering. It would seem somehow more logical to me, although related to a use case I don't find very logicial - so I don't need really this improvement to be done.