I looked in to this and it would require a pretty big rewrite of the image handling in order to fix, so I'm going to classify this as won't fix and a small note to the readme.
Thanks for bringing it to my attention, it's always interesting (and often painful) to learn how flexible the renderer is.
I think it's fair to leave it as it, doubt it's a common use case. Thanks for checking.
Fun fact: the reason there was a multi line title in the first place is that this resource has been attached in One Note initially. Apparently it runs OCR and adds extracted text to metadata. Then when I converted One Note -> Evernote -> Joplin, the text ended up as the resource title.
Awesome! Absolutely love this plugin, I really appreciate your work in writing it.
Would be nice if tables could be rendered, then I could totally switch from the WYSIWYG editor.
Joplin has hard-crashed my Mac twice in the past 24 hours. This is the only active plugin, so it's either Joplin itself (v2.5.4) or this plugin (v0.7.3).
The problems started when I noticed one of my long (30k characters) scratchpad notes lagging when typing in it. I tried disabling this plugin and the lag went away. It seemed to stay away when I reenabled it, so I didn't think much of it. Maybe it was just happenstance; I did have to restart to disable the plugin.
After that, I started diving into the plugin's style capabilities -- specifically, using the "active line" functionality to hide the URLs of links. Visually, that's my #1 issue with Joplin, so I was glad to finally find a solution.
Well, since enabling the "active line" stuff and editing userchrome.css slightly, I've suffered two hard crashes. Joplin freezes, my Mac's fans briefly hit peak, and then the whole thing shuts down. The error on restarting will call out a Joplin render helper.
I don't know how to dig any more useful information out of things, but suffice it to say I'm thoroughly annoyed with whatever's going on.
Hi @CalebJohn , there is another missing CSS class. The footnote. While the Markdown footnote have the #markdown-footnote , .footnote-sep , .footnotes , .footnotes-list , and .footnote-item , the Rich Text Editor footnotes didn't have any CSS class. It's a bit annoying when a user switches between two editors to use for a personal reason sometimes. It would be lost the CSS styles of the markdown footnote and become a normal hr and ol > li styles when the format change to Rich Text.
The markdown footnote seems will change to Rich Text format automatically when I try to edit whatever things are in the rich text editor. I won't expect that Rich Text Editor to support all markdown formats but it better at least can keep the same CSS styles through the CSS codes.
Or, is there any other suggestion that can avoid the format change automatically?
I would be too, it's an annoying situation. You could probably try disabling this plugin for a few days to see if the crashes go away. As you mentioned, there isn't much useful information yet, so this might be a bit of a waiting game.
I think if I understand you correctly, the trouble you're facing is that you're losing footnote highlighting/formatting when switching to the rich text editor? If thats right, then there isn't much I can do to help you here. The purpose of this plugin is to extend the functionality of the Markdown/plain text editor, it doesn't touch the rich text editor at all.
You could perhaps suggest a plugin.
Thanks. I've actually tried that already but it breaks rendering for numbered lists as they are also shown as dots. Also when using asterisks for bullets now two dots are shown.
I have a long note (~2000 lines) where the rich markdown plugin leads to lagging. I can finish typing a full sentence before the letters appear. If I deactivate the plugin, editing works flawlessly.
Windows 10, Joplin 2.5.10, Rich Markdown Plugin 0.7.3, but the problem started to occur months ago.
Can't share this particular note, but it happens for this Lorem Ipsum note with 2800 lines too. With the Rich Markdown Plugin activated, typed letters and sentences appear with a delay of around a minute. With the plugin deactivated: No problems.
Thanks for sharing this @Prinplup, it was super easy to reproduce using it (although luckily changes appear after about 5 seconds for me, not 1 minute). This will be fixed in the next version.
The performance issue was due to some code for highlighting code block backgrounds. While this was added to the main app in v2.3.4, this plugin supports v1.8.0 and up. Due to some other changes, I was planning on bumping up the minimum version to v2.4.0 anyway, so I'll go ahead and remove that functionality at the same time.
Or the Folding in Code Mirror Editor plugin if you want something that works in the markdown editor. You can do a forum search for more info. But this thread isn't really the best place to ask.
@CalebJohn I'm noticing that if I delete the text that inserts an image (usually created using the web clipper) the image seems to freeze in the editor, no matter what note I go to. I'm guessing this is because of the "Enable image popup even when Ctrl (or Opt) is not pressed" option I have selected, but obviously it shouldn't stay popped up after it's markdown source is deleted.
Or use the details tag like below. I came across this on some other post on the forum a long time back. I find it particularly good with PDFs, to hide them until the heading is expanded.
<details>
<summary><b>Read more</b></summary>
Leave a blank line before the content that's to appear
Markdown **works** fine between *these tags*
</details>
Read more
Leave a blank line before the content that's to appear
@CalebJohn The editor is still jumping around for me when I have "Render images below their markdown source" enabled. Whenever I scroll to a location, a second or so later the location will jump a bit which is pretty disruptive.