This is a continuation of this discussion which Daeraxa so unhelpfully locked, not before regaling us with a snappy answer.
Yes, as from release 2.5.4 Joplin can import / export markdown frontmatter. That is very good, thank you very much. However that's not what we were asking for.
What we are asking is for the frontmatter EDIT to contain aribitrary properties, which are not lost on import, are editable, and can be exported. TO STAY THERE, in the note. as frontmatter. Importing a note with front matter simply strips it away. That won't do. I want to be able to edit it, search through it. I simply don't want it to show up in the rendered note. Just like it works in countless other tools. Hope this makes things clearer
We close old topics when there has been significant development since the original post, new topics have an auto close but the old ones don't. It causes significant confusion when people assume a feature still isn't available when it has been for months or years even if the most recent post deviates from the original intent.
YAML frontmatter support was added, if additional functionality is desired then you are welcome to open and link a post as you have done.
Sorry to be pedantic, but YAML frontmatter support was NOT added.
What was added was the ability to strip away frontmatter when importing a .md file, and the ability to add some arbitrary frontmatter over which we have no control when exporting the file as .md. I cannot see nor edit that frontmatter. It's a welcome step forward, but that isn't support. Unless I am missing something, of course, which is very much possible
The frontmatter support added was to this spec as a way of importing and exporting metadata that would otherwise be lost (or at least not integrated).
You can certainly edit most of them, outside of integrated things like tags, on the desktop app you can press the little i symbol in the top right (or the showNoteProperties command) and it will show which fields can be edited with the pen/paper icon thing.
Oh and you can search most of them (if not all) with the built in search filters
OK, thanks for the tip. That is better than I thought. Still, I miss the ability to have arbitrary properties in the frontmatter. For example my notes have an 'excerpt' tag that gets swallowed on import and is never to be found again. I guess the topic then should be 'ability to add arbitrary properties to yaml frontmatter'. I will edit the title
I guess the question would be where to put it.
I'm assuming the simplest method would be as a new category in note properties which could hold arbitrary key-value pairings.
Adding search support for it I imagine would be harder but I guess still within the realm of possibility.
Now that bit is sorted, I understand the frustration in having the topic locked and I could have been more helpful in the closing post but that tends to happen when people leave comments which come across as confrontational, particularly around a feature that had already been added in an organisation/community made up entirely of volunteers.
Additional enhancements/feature requests to extend it are obviously welcome but a new topic is definitely the correct place for it rather than extending the discussion of an old one so thank you for editing the original post to reflect it.
So is the issue that tags are not imported? Because we support tags in the frontmatter header, and normally if they are in the format specified there they should be imported:
My understanding of it is that 'tags' in this case is just the wrong word and instead it is just related to additional arbitrary fields which according to the spec:
title: Joplin Interop
created: 1970-01-01 00:00Z
tags:
- export
- import
excerpt:
- This exporter/importer is built around the MD exporter/importer. It functions identically, but includes a block of YAML front matter that contains note metadata.
...
And the goal of this request is that the data is retained and could be queried but not stored in the body of the note.
Thinking about what I said in a previous post, could there be merit in an additional note properties field (e.g. "additional properties") to store such data? It doesn't need to be restricted to this, I think there have been plugin developers asking if "note level" storage like this could be used to store plugin related metadata outside the note body so I can see it being quite flexible.
It would be really interesting because, if I understand correctly, it would allow to add custom fields. I dream for example to have a "scheduled" with a date value in which I could search for todo...
