what is the output of show debug info
Attach a copy of the file where this happens.
SYSTEM INFO:
Obsidian version: v1.1.16
Installer version: v1.1.15
Operating system: Windows 10 Home 10.0.19045
Login status: not logged in
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on
RECOMMENDATIONS:
none
What happens if you put a blank line after the comment?
If in Editor settings you enable Strict line breaks, the problem goes away.
But I never remember having that option activated before and never experienced this issue before.
Tried it before. Not helping.
I have strict line breaks turned off, and adding a blank line after the comment fixes the problem for me.
This shows a single blank line in Reading View, as it should:
Ghjbghjkkhhj
%%Hgghjj%%
Vvdfghnn
This shows an extra blank line in Reading View, as you described:
Ghjbghjkkhhj
%%Hgghjj%%
Vvdfghnn
That indeed works.
But I think the program handling this is not ideal the way it is.
I have many many notes where I have multiple lines I decided to not publish and they are all lining up underneath each other with no empty lines. I could put some extra line there with regex of course, but still…
In general it’s a good idea to put blank lines between blocks in Markdown. Sometimes it’s required, and doing it the rest of the time keeps things consistent and avoids having to remember when it’s required and when it’s not.
But I agree, it looks like a bug. (I’m not the person who decides what’s a bug, tho.)
1 Like
The problem I had to start with was that you cannot include multiple lines with carriage returns and all with one %% pair in front and one at the end. You need to pair them off on each line.
I’ll be looking out for this in the future and before I need to publish I will run some regexes to be safe.
Multiple lines inside a single set of comment markers works on my system. EDIT: And, strangely, doesn’t show the extra space problem.
This gives me a single blank line:
Vvdfghnn
%%Hjkk
Hdhfh
Hhj%%
Bhjj
I seem to be remember so but other times it didn’t. I don’t know if it has to do with soft line breaks (I always have two spaces).
- Mind you, 99 percent of all comments were made with regexes, not as I typed.
By the way, https://markdownlivepreview.com/ doesn’t handle this %% comment thingy at all. Don’t know about GitHub.
That comment syntax is specific to Obsidian (in some usages it also works in Ulysses). <!--HTML comments--> are more widely compatible.
1 Like
It indeed works on multiple lines with soft line breaks.
But now I remember how it all happened: first I was using strikethroughs and then I decided that the reader should not see those deleted ideas (for fear of losing face). But because my strikethroughs were on multiple lines including lists (sometimes multiple lines deep), the structure of start and end was breaking and along with it, the comments as well.
Anyway, I hope it is treated as a bug, otherwise I need to manually oversee what behaviour needs attention.
Indeed, I see it elsewhere online:
“For maximum portability it is important to insert a blank line before and after […] comments.”
thanks
Steps to reproduce
- Add a heading
- Add a comment to the following line
- Add an internal link via
![[Note]]to the following line
Did you follow the troubleshooting guide? [Y]
Yes
Expected result
There shouldn’t be extra space added between the heading and the inserted link. I’d expect comments to have no effect for the reading mode, but in this case, they do:
if the comment is left out, there is no extra space.
Expected:
Actual result
Environment
SYSTEM INFO:
Obsidian version: v1.3.7
Installer version: v1.3.5
Operating system: Windows 10 Pro 10.0.22621
Login status: not logged in
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: off
Plugins installed: 0
Plugins enabled: 0
RECOMMENDATIONS:
none
Additional information
1 Like
This is a duplicate of %% Comment text blocks -- Unwanted extra lines in Reading Mode.
Also, a nitpick that doesn’t change your point: That’s an embed, not a link.
1 Like