Also experiencing this issue with Rust.
Live-Preview:
Read Mode:
Edit Mode:
My guess is Obsidian thinking there is an unclosed HTML tag. If there was a way I could just get Obsidian to treat HTML as plain-text in Source Mode I would be happy.
1 Like
I have the same issue with HTML and CFM code blocks.
Like many have said, I would suspect obsidian gets confused when it see another > symbol in the line.
Idk for sure how all of this is coded to work but it seems to me that this should be preventable by only checking for the > character at the beginning of a line.
so if I have >> <div>
the first 2 are > characters so obsidian should look at them and render properly based on that. Afterword’s, we have a < character which doesn’t continue the pattern of > characters hence obsidian should ignore all > characters that come after that point for that line.
If that logic was added I’m pretty sure it would fix 99% of the issues people are having in this thread.
I also came here just to report this bug.
I use code blocks in the callouts / blockquotes, and when the code block contains anything like <xxx> it breaks the Live Preview from that place on until the end of file. Read Mode works correctly.
Example (put this into Obsidian):
> ```
> Code block which contains <this> will break the live preview.
> ```
> This isn't **formatted** correctly anymore, same as rest of the file.
The problem seems to be that Obsidian tries to interpret <this> as html tag, but it shouldn’t, because we are in the code block. It should take the whole content of code block as is. And as mentioned, in Preview Mode it behaves correctly.
4 Likes
Not sure if this helps but I know with Admonitions you can use ~~~ code block ~~~ and that works there but I tried it with call out and it seems to work there as well. So within the call out if you want a code block use ~~~ instead of a ```
The only issue I ran into with this is the empty lines, how I got around this was to either look through the block and add > to the beging of the empty line or just highligh the entire block and use comand - p and type callout, this will automaticlly wrap the whole thing selected in a code block and put the > on the emtpy lines as well for you.
It would be nice to be able to use these as I do with admonitions but I have to stick with callouts as I have soem custom SVG I like to use in a CSS file and I cant seem to get the custom SVG to work with admonitions.
I can’t believe I haven’t seen this proposed: since Obsidian can render HTML, if you wish to display characters in code or strings used in HTML syntax should be escaped.
Use the HTML escape entities < > for the angled brackets in any strings / code, so it doesn’t interfere with markdown language. It’s effective without messy workarounds.
Don’t do that.
Note: you can escape using \ before the character, which function as the backticks `` (show backticks: \`\` … show backslash: \\ )
And it is the most readable in editor mode.
@AndyOfClapham You can’t use escaping in the multi-line code blocks (defined by 3 ticks ```).
But the main issue is that editor mode has broken rendering, while it works correctly in the reader mode. The parsing/rendering rules should provide same result whether I’m in editor mode or in reader mode. That’s bug.
2 Likes
There is a difference in the rendering engine used in live preview versus reading, and there is some differences in how these handle various cases. This being one of them. It’s as such not a bug per se, but more of a feature related to these differences of the rendering engines.
One could possibly try raising an issue on the home site for code mirror which is the one used in live preview… I wouldn’t hold my breath waiting for a fix though.
2 Likes
+1 This render bug is kinda annoying. (I don’t use codeblocks in callouts/quote blocks that often, but when I do…)
3 Likes
+1, same issue.
I often use blockquote (or callout) to “pack” codeblocks and forumlas with several explanatory paragraphs together, so I can use [[filename#^block-id]] to refer them as a whole elsewhere in my vault.
So this rendering problem is quite annoying, sometimes I have to use VSCode to edit the source code. If this problem can be fixed, it will help a lot.
3 Likes
+ 1, in editing mode, the code block is poorly rendered. Because of this, it is not possible to set the margins normally.
Same problem here for me. I have a lot of code snippets mostly with bash commands and use <TEMPLATE> to mark spots where input is needed. BTW I have two workaround for this:
-
Use `` like this `<TEXT>`
-
Put a number in front of the text like this <0TEXT>
Both should be able to help, though they will be useless for people using it for HTML.
Found a similar solution thanks to your post. Instead of using a number, I found that a zero width space works well and doesn’t display anything: <TEXT>
2 Likes
Nice solution if you wish for it to look clean, but I am afraid of one of those characters getting lost in a snippet and causing havoc. ZWS-es are dangerous. Maybe a small CSS snippet could be used to hide the number? I am going to investigate this
As for equations, my plugin Better Math in Callouts & Blockquotes solves this issue.
As the title says, the live editor seems to crash if a < or > is within a HTML case using “body”. It’ll default to the normal editing mode.
I am fairly sure this issue is exclusive to the Live Editor because the read mode displays the note fine.
Steps to reproduce
Create a note and paste the following at the top while in Live Editor mode. Text after the first callout will stop working properly.
[!abstract]
The technical aspects and economics of bulk hydrogen storage in underground pipes, lined rock caverns (LRC) and salt caverns are analyzed. Hydrogen storage in underground pipes is more economical than in geological caverns for useable amounts <20-t-H2. However, because the pipe material is a major cost factor, the capital and operating costs for this storage method do not decrease appreciably with an increase in the amount of stored H2. Unlike underground pipes, the installed capital cost of salt caverns decreases appreciably from ~$95/kg-H2 at 100 t-H2 stored to <$19/kg-H2 at 3000 t-H2 stored. Over the same scale, the annual storage cost decreases from ~$17/kg-H2 to ~$3/kg-H2. Like salt caverns, the installed capital cost of lined rock caverns decreases from ~$160/kg-H2 at 100 t-H2 stored to <$44/kg-H2 at 3000 t-H2 stored. Storing >750-t useable H2 requires multiple caverns. The cost of salt caverns scales more favorably with size because the salt caverns are larger than lined rock caverns and need to be added at a slower rate as the storage capacity is increased.
tasty bold text
[!SUMMARY] The Point™
The point is that you own this folder just like the other folder of camping photos that you created yourself.It’s supposed to be a good thing because you get both data ownership and privacy this way.
Expected result
The note is displayed well.
Actual result
Editor defaults to the non live editor mode.
Environment
SYSTEM INFO:
Obsidian version: v1.4.13
Installer version: v1.4.13
Operating system: #92-Ubuntu SMP Mon Aug 14 09:30:42 UTC 2023 5.15.0-83-generic
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
This issue still exists and there is currently no workaround.
1 Like
