Links in hierarchies are not updated when renaming files (Part 2)

Continuation of the previous topic:

I found what was the bug and highlighted it.
The html tag hr was found on note pages.
It stood for many pages (above the list and the head of the list).
Now the mistake can be repeated.
The steps are the same, just rename the file.

This happens not only in trees, but also
when the link is next to the html hr tag.

<hr> is unclosed in your notes. Does the issue persist if you close it: <hr />?

In HTML, the hr tag does not have an end tag.
The closing tag doesn’t work here.

The Obsidian command “—” works like hr. Here I do not use it only because it spoils the size of the top line. I need to do extra line breaks.

Replacing it with an html block won’t work either.

Your screenshots are quite tough to follow. Just post your raw text examples wrapped in ```

You need a blank line after HTML blocks, else the processor does not pick up the following lines as markdown.

Fine. The div tag has zero height. If you insert it before the hr tag… No, both lines are combined into one common html code.
I will consider that it is impossible to do this, that this is a feature of Obsidian.
Thank you. Close the topic.

It’s just that your continuous lines are recognized as one block.

Add a blank line after your hr or div tags and it’ll work.

Extra blank lines interfere.
Especially if it’s almost at the very top of the page.

There is some strangeness occurring, adding whitespace does fix to some extent, but here is an example of the strangeness:

<span><hr /></span> 
<hr /> 

Which in 1.1.9, displays in reading view as:

So the --- causes the previous line to be considered a heading, as per markdown syntax.

The <span><hr /></span> does produce the line (and some extra space), and is a closed html structure, so that the next line is shown as a proper link. (The same doesn’t happen with <hr></hr>, which is wrong html, but could possibly have worked)

Even the self-closing <hr /> doesn’t work in reading view, as it then triggers the strangeness of causing the next few lines to be treated as something else…

I’m not sure you’d want to call that a bug or a feature, but there is also a difference in reading view vs live preview on the above example, where the links are all showing in live preview, but then <hr /> doesn’t work, and it does a better job with <hr>.

So strangeness occurs, but I’m not sure how to classify this. When doing the actual renaming of 2019-02-26, it doesn’t rename the last three versions, as they’re clearly not considered links, but rather some simple text (of sorts).

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.