This is another bug fixing release. There were several bugs that accumulated since the last release. Some that just cropped up, and others that were a little bit longer standing. Thanks to everyone that reported these issues and helped me get them fixed.
This is a very small release related to the previous patch that added support for watching image changes.
In some cases that change could cause the cursor to jump around. It also caused the spellcheck underlines to flash periodically. Both these issues have now been fixed.
This is fantastic, I am looking forward to turning off the rendered view, as I was mainly keeping that for links and checkboxes.
Feature requests:
The rendered view will currently convert any URL into a link, even if it is not within Markdown formatting. It seems that Rich Markdown plugin does the same (Ctrl-click does open the link) but it is not formatted as a link (blue, with underline) - can this be done as part of the plugin? Or should I just use custom CSS to override it? I see it has a cm-rm-link class on it.
I like how <details> can be used to show/hide content in the rendered view. Is there any possibility to have this behaviour in the editor view with Rich Markdown?
In general I try to avoid adding new styling through the plugin, and instead add CSS classes that will allow the user to customize how they want. So this is something you'll want to add through CSS. I have some tips on how to handle that if you need to to work across multiple colour schemes.
That said, having a couple of pre-built themes is on my wishlist for this plugin. So in the future users that aren't comfortable with CSS will have an option.
This is a good question. I sort of see this plugin as bringing functionality from the viewer and placing it in the editor, but I have also added a number of options for theming so it's not like I stuck to the perfectly.
That said, there is an existing plugin to allow folder of headers in markdown, and it might be a better fit for this request.
Adding this feature exactly as you describe would be quite challenging, but basically the same thing could be added using an editor plugin.
Is there any chance of having an option in the right click menu for copying a link, as you might in a browser? Of course you can just select the link and then copy, but it would be nice to have the copy link feature.
That's a good idea @whitewall.
I've added a feature request for it on GitHub to help me track it better. I think to do it properly the plugin system will need to be extended a bit.
Same suggestion about copying a code block. That is actually why my friend moved to Obsidian: he's a programmer and he loves the one click copying of an entire code block. Not sure if that is possible at all with Joplin or if it is within the scope of this plugin, but I know it would probably be a huge deciding factor for him to come back to Joplin
When that functionality was added to the plugin, there wasn't a way to get access to the Joplin theme colours aside from re-using a class. In this case, Joplin uses the same colour for the search marker and the highlight, so I used that class to ensure the plugin highlight would match your Joplin theme.
Joplin theme colours have now been exposed, so I can update the plugin to take advantage of that instead. Thanks for the reminder!
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?
