Is there a way to make Joplin understand that if the note starts with three dashes than it is YAML and it should show it say as preformatted text till the ending three dashes?
Adding extra new lines and ugly hacks the display problem, but the dashes are interpreted as break.
Why not use a yaml code block?
```yaml
Front matter: here
```I never thought of that and it's a great solution while in Joplin. But once exported, apps like say Hugo: The world's fastest framework for building websites gohugo.io, won't play that nice. That's why I'm looking for a way that Joplin will get
---
data: X
variable: Y
---
and not formatted if these are the first characters.
Sounds like you need a plugin for this.
You need to write a joplin data api plugin. . .
I also think this is an absolutely necessary feature.
Why is it necessary? Someone mentioned Hugo earlier -- there's now a plugin to export notes to SSGs including Hugo. Are there any other use cases?
Hi @roman_r_m
Yes of course there are many other use cases. In my circle of friends, Joplin is used (and could be used even more) to take notes for research purposes. More and more researchers want to get rid of word processors and compatibility problems (libreoffice/MS). There is a tendency to open a Nextcloud for a research team (or with students) to share (and encrypt) data. Working in markdown allows to keep the objective of a reproducible research and to ensure interoperability. The txt formats are ideal for this (md, org, txt, etc). But many need to manage the complexity of writing an article, report or thesis in their markdown source files. In this area, Rmarkdown for example does an excellent job for graphics, data visualization. But everything works with a YAML header...
So yes we could use Rstudio or Zettlr as an external editor but in this case, we lose the benefit of the Joplin plugins which are very useful and more and more numerous.
This is a use case anyway.
I think MarkdownIt parser used by Joplin can recognize three dashes as it's used for the delimiter, so this looks doable in a plugin.
Just a simple thought: wouldn't it make more sense to ask developers of apps that support YAML front matter metadata blocks to also support the YAML code block syntax?
I mean, a Markdown code block is pretty robust and should survive virtually any editor, no matter how badly conceived. So if the target apps support them, that would turn any Markdown tool a de facto proper tool in the tool chain -- without requiring a single modification, extension, plugin, or even any understanding of the issue.
The devs that develop apps like Hugo have a much better understanding of the reasons why and what it would mean to add support for this.
Thus my vote (if this was a democracy) would go to the YAML code block, as it seems manifest destiny to me.
Just my two cents.
The "standard' says the YAML metadata of Markdown document are between two --- and all static content generators and GitHub itself respect that.
The problem is not about static generators, but about allowing any editor in the tool chain without destroying the front matter data along the way.
Nextcloud, notably, doesn't accommodate the actual standard. And I'm pretty sure it's not the only one out there. The problem is that most apps will interpret --- as horizontal rule and anything else as normal Markdown, not as YAML or code or whatever. Any editor shipped with Nextcloud will sooner than later break the syntax and turn any precious front matter metadata upside down.
Since I haven't found yet any better solution to store metadata inside text documents (nor the time to come up with a better idea), I annotate my Markdown documents using front matter syntax enclosed in YAML code blocks. Nothing besides me understands it for now, but at least it doesn't get totally messed up when edited and it's at least based on something.
I'm only suggesting that adopting the alternate code block syntax in the standard would solve this compatibility issue without needing any specific implementation or plugins or black magic incantations in existing software. Not that I actually care, on a personal level.
Just my extra penny.
+1 for YAML front matter. It's pretty standard across a wide variety of tools, easy to implement and you can simply ignore it if you have no use for it. I don't get why it's even up for discussion to be honest
Seeing as it was added months ago, it isn't.