Joplin version 1.0.179

  • New: Added new, more secure encryption methods, so that they can be switched to at a later time
  • Improved: Improve appearance of note Info dialog
  • Fixed: Apply userstyle again when exporting to PDF or printing (#2324)
  • Fixed: Fixed update message box
  • Fixed: Fix identification of note in pdf export from main menu. (#2323 by mic704b)
  • Fixed: Undefined text was being displayed on top of notes in revision viewer (#2352)
  • Fixed: Fixed issues with Katex and MultiMd table plugin (#2339)
  • Fixed: Fix Linux installation script (#2333 by @carlbordum)



In v179, the single pipe is recognized as something special again, but it isn’t treated as in v175. This is my Markdown:

| A | B | C |
| - | - | - |
| a | b | c |
| e | f | g |
| i | j | k |

| p | q | r |
| t | u | v |
| x | y | z |

It was rendered as the left table below in v175:

The new mmd plug-in splits the table up along the section boundaries (center). When I remove the single pipe in the middle, the sections are glued together again, but the resulting alternation of row colors isn’t very pretty (right side).

However, when I type two or more consecutive pipes (without spaces between them) on a line, I get the left table back. So there is a remedy, but I still have to repair my tables.


It appears that the link for the portable application on the homepage is still pointing to the version 1.0.178.

I was surprised when I downloaded the package by following this link and was prompted to update just after starting it.

Please note that you were referring to the multimarkdown table plugin. On one side it could be a side effect of changes we made in Joplin, but It could also be a change in the plugin code, which then is out of our purview. I haven’t worked with multi-md tables, so I don’t even know, if your syntax is correct according to their specs. But the first part is definitely wrong:

| A | B | C |
| - | - | - |
| a | b | c |
| e | f | g |
| i | j | k |

The line with the single pipe means that the table does not use a header. So it can’t be rendered as you are showing above. It is rendered as follows (at least on my Joplin - git master 7fd4451):


So it seems, the plugin changed the behavior.

The coloring of the table rows on the right side of your example above is technically correct when you trace how our default table css is setup and how multimarkdown table extension “joins” 2 tables when they are separated by a single line.
Also, splitting a table with a single pipe does not seem possible according to their specifications. It would then be considered a new table.

While I agree that things like these are annoying, they are also very hard to mitigate. If plugin devs decide to change their code, there’s not much we can do.

It’s also the reason why it’s best to avoid using non-standard Markdown features as much as possible (I know it’s not always possible).

We provide these plugins but they aren’t standard so indeed their behaviour might change, and when you export your note to an MD file the syntax might not be supported by other viewers. We try to mitigate this by tweaking or updating plugin options as they change but it’s not always possible. In general sticking to the standard is good for data durability.

Yes, all the time I was fully aware that I was using features that can be plugged in and plugged out. OTOH, I had no idea of the demarcation of involvements and definition of responsiblities with respect to plug-in production. The answers of @tessus and @laurent leave me with the impression of a collection of unidentified third parties (UTFs) that can only be controlled to some extent by best effort. This setup doesn’t look as being the most mature part of how the development of Joplin is organized.

I also realized that using some features would possibly make my writings incompatible with the outside world. I don’t care much about that aspect, as the outside world is incompatible with itself, and only Pandoc is trying to understand all Markdowns (including its own one). I did some googling today, and these look currently the most prominent ones to me:

(layed out according their presumed lineage). This is only the top of the iceberg. See and try Babelmark. I wonder if using Markdown is a good choice. Why not AsciiDoc (see also AsciiDocter) or reStructuredText (reST)? No forks of them known to me. Okay, Markdown is unmistakably the most popular… because it’s the most popular. The de facto standard.

When I was thinking about a new desired Markdown extension, I couldn’t resist peeking into some plug-ins to get an idea about how complicated it would be to create them. I didn’t delve very deeply, but nevertheless I noticed that a lot of parsing was done by plain JavaScript. Exclusively, or with help from some non-JavaScript libraries? I don’t know. And I saw a lot of apparent interface overhead. The current plug-in provision is not as flexible as in my web browsers: 14 are pre-installed, no more, no less, exactly those 14. Can it be made more open? An interesting question. The order in which parsing algorithms are processed may decide the result. So some centralized orchestration of plug-ins seems inevitable.

Anyway, my table case can be closed.

The problems should not be overblown either - it’s not like there’s a bunch of out of control plugin developers randomly changing stuff in Joplin. We’re careful with our upgrade and do our best to make sure each version is backward compatible, but small rendering changes can happen (although I expect it’s very rare) as happened for the multi-md-table plugin.

If you have any suggestion on how to improve this, feel free to let us know. Perhaps it would be best to clarify in the documentation that plugins add non-standard features, which therefore might not work in other Markdown readers.

I didn’t want to insinuate a horde of madmen. My point is that there are just some parts where you are not in full control. In fact nobody is, in some chains of components. Let’s call it an interesting situation.

As I don’t have any insight in how the plug-ins come into being (Do you have contact with the developers? — Do you simply come across some usefull software on the Internet which make you decide to copy it? — Is there any documentation available?), I cannot even start with an analysis and conceiving solutions. But if I get some ideas, I’ll let you know.

That’s not a bad idea, albeit not an issue that really troubles me. In addition, there is a tiny complication: what is the standard? Gruber’s Markdown? Then soft breaks are the standard, and the first plug-in removes the non-standard behavior! (I regret my decision at that time to check this one, BTW. It turns out to be very annoying. I’d better revert it before my textbase has grown too much. And in some rare cases, I can always do the trick below.)

What a hell of witchcraft lies <!--
You don't see me!
--> in the small orb of one particular tear?

These are markdown-it-* plugins and can be found on npm. e.g. multi markdown table
We have alrady contacted a few developers and asked them tp fix bugs, which btw is not always that easy. But the dev of the toc plugin was very helpful in the past.

Rather people who use Joplin asked to include certain features, which were available as markdown-it plugins.

Joplin always used hard breaks since the beginning. Some people were used to have their markdown with softbreaks and thus the rendering would look different in Joplin. This is why I added the option for the people who like to use soft breaks.

DRIFT, good job! :slight_smile:

Thanks for the links. Is there any relation with this one (apart from just being the x-th shade of Markdown)?

Not sure what that means.

Yes, Joplin uses this for rendering the markdown.

DRIFT is the odd abbr of Do Things Right The First Time. Not quite my taste of composing acronyms.


I’ve now updated the doc to mention that we follow the CommonMark spec, and that plugins can potentially make the Markdown text incompatible with other apps.

1 Like

I can not download the version 1.0.179.
I have tried several days, is there any other way to update the joplin?