[BUG] Markdown hierarchy appearing wrong in navigation panel

[blue-baloon]

My Setup
QOwnNotes Version: 24.3.4 Portable
Windows 10 Pro version 22h2
Processor: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz 3.10 GHz
RAM: 8,00 GB

Expected behavior

In the note navigation panel, the expand/collapse behavior (parents) should be:

# 1
   ## 1.1
      ### 1.1.1
      ### 1.1.2
      ### 1.1.3
   ## 2.1
   ## 2.2
         #### 2.2.x.1
         #### 2.2.x.2
         #### 2.2.x.3

Actual behavior

In the note navigation panel, the expand/collapse behavior (parents) happening is:

# 1
   ## 1.1
      ### 1.1.1
      ### 1.1.2
      ### 1.1.3
         #### 2.2.x.1
         #### 2.2.x.2
         #### 2.2.x.3
   ## 2.1
   ## 2.2

The h4(2.2.x.x) titles should be 'child' of '2.2' but it appears as 'child' of '1.1.3'

Sometimes in my notes, I use the number of (#) to group issues according to their importance or subject, so not every time I have a perfect sequence (#, ##, ###, ####) I mean, some of them may be skipped.

In my example, since the h4s are after the h2s in the text I believe they should be grouped accordingly in the panel, but contrary to that, the h2s got thrown down and the grouping got messy

Steps to reproduce

Open a new note, paste the following text, and see the behavior of the note navigation panel

# 1
## 1.1
### 1.1.1
### 1.1.2
### 1.1.3
## 2.1
## 2.2
#### 2.2.x.1
#### 2.2.x.2
#### 2.2.x.3

Print Screen:

[pbek]

Hm, the used "algorithm" searches for the previews heading that is one level higher, that is ### 1.1.3 in your example, since you skipped the proper ### heading after ## 2.2.

[blue-baloon]

Hm, the used "algorithm" searches for the previews heading that is one level higher, that is ### 1.1.3 in your example, since you skipped the proper ### heading after ## 2.2.

Yeah, I skipped h3...

Like I said, maybe I use the hierarchy in a 'particular' way, but I thought the algorithm should also consider the typing position in the file.

To explain better, I always start typing subjects using h4 and under it I put

(normal text) to explain in details, if the issue belongs to some group, I add h3, h2 and h1 to organize it, for better understanding and visualization of priorities.

If what I did is considered wrong, I apologize and ask you to close the issue

Sorry for my English

[pbek]

If what I did is considered wrong, I apologize and ask you to close the issue

"Wrong" is a harsh word. 😊 It's more like in HTML or Markdown you are not supposed to skip heading level...

The current implementation of finding a suitable parent is:

QOwnNotes/src/widgets/navigationwidget.cpp

Lines 185 to 195 in 3cd56c6

	/**
	* Attempts to find a suitable parent item for the element type
	*/
	QTreeWidgetItem *NavigationWidget::findSuitableParentItem(int elementType) const {
	--elementType;
	auto lastHigherItem = _lastHeadingItemList.value(elementType);
	return (lastHigherItem == nullptr && elementType > MarkdownHighlighter::H1)
	? findSuitableParentItem(elementType)
	: lastHigherItem;
	}

Works great for a valid Markdown heading structure. ️🤷🏻

[blue-baloon]

If what I did is considered wrong, I apologize and ask you to close the issue

"Wrong" is a harsh word. 😊 It's more like in HTML or Markdown you are not supposed to skip heading level...

The current implementation of finding a suitable parent is:

Works great for a valid Markdown heading structure. ️🤷🏻

Yeah, like you said, it's not recommended.

I took a quick read at this interesting discussion about this topic:
Heading off confusion
The entire text is interesting, but the comments are gold... No consensus at all if skipping headings should be considered wrong (prohibited) or just 'non-recommended' but acceptable.

Initially, when i opened the ticket I just wanted to show this 'unexpected' behavior to the devs; well, it's done.
If you consider the behavior normal, well, I'll adapt and live with this.

You've been very kind regarding this issue, thank you!

And again, sorry for my broken English

[pbek]

You've been very polite too! 🙏🏻
I'm not even sure on how easy it would be to do anything about it and if it would cause problems in different cases...

[pbek]

Phew, it's rather hard to find a more suitable parent item if the structure isn't valid...

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.