Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: express key/value metadata as YAML front-matter #508

Closed
usergenic opened this issue May 9, 2018 · 9 comments

Comments

@usergenic
Copy link

commented May 9, 2018

Markdown files used by Tusk would be more easily repurposed as-is if the metadata key-value pairs which sit in the tail of the document were expressed in the head of the document followed by a --- which would make them work essentially as YAML front-matter which is specially handled by many markdown renderers as invisible or specially formatted.

@laurent22

This comment has been minimized.

Copy link
Owner

commented May 10, 2018

Thanks for the suggestion but I'm afraid the format will not be changed. It's this way because it's more convenient to see the title, body and then the less important metadata.

@laurent22 laurent22 closed this May 10, 2018

@usergenic

This comment has been minimized.

Copy link
Author

commented May 10, 2018

Fair enough. Cheers :)

@NGenetzky

This comment has been minimized.

Copy link

commented Sep 13, 2018

@laurent22 , I too believe this would be a valuable enhancement. Data attached to markdown in the described format is widely supported by various static websites and libraries. I would love to encourage this with a donation 👍 .

I am literally considering a post processing step that moves the metadata.

@laurent22

This comment has been minimized.

Copy link
Owner

commented Sep 13, 2018

It's definitely not possible to switch to a different format, whether it's yaml, or xml, or json, etc. But also I don't see what would be the benefit of doing so?

  • The current format is trivial to parse (just key/pairs separated by ":"), so there's no benefit switching to eg yaml. It just mean that the key/pairs would be separated by "=" instead.

  • Even if you had an editor that hides this metadata, it doesn't mean you can edit the file and it will sync with all the devices. For this to happen, you'll also need to update the timestamp updated_time, so the editor would need to have a custom plugin and just using yaml won't solve this either.

@NGenetzky

This comment has been minimized.

Copy link

commented Sep 14, 2018

It's definitely not possible to switch to a different format, whether it's yaml, or xml, or json, etc.

Was this a typo? I assume you meant to say it is possible.

The current format is trivial to parse (just key/pairs separated by ":")

Sure it is trivial to parse but its a custom data format. Can you imagine if everyone used a custom data format? The libraries mentioned above or similar ones should be able to completely handle the metadata associated with the markdown documents.

it doesn't mean you can edit the file and it will sync with all the devices. For this to happen, you'll also need to update the timestamp updated_time

You bring up some good points. I don't think manual editing can easily be done, but I think your application does a good job helping with that part.


One of my primary reasons to switching to Joplin was to avoid "vendor lock" of my data. I was absolutely estatic that you seem to like plain text as much as I do. I only imagine the extra benefit if the markdown documents produced (by Joplin) were compatible with the markdown documents consumed by static web site generators (such as Hugo or Jekyll). The popularity of your application could easily skyrocket as the goto for bloggers and static_site lovers.

@Philiphlop

This comment has been minimized.

Copy link

commented Jan 4, 2019

One of my primary reasons to switching to Joplin was to avoid "vendor lock" of my data.

I think this is a very important point to not overlook. It's completely understandable that such a change is an amount of work that isn't necessary for the function of this app. But it is the ideology of us being able to truly own our data. If we continue to use Joplin and build it out how we want, we lose that in part. Yes we can create a script to go in and pull those details out, but things can get complicated fast. Even the export feature to MD does not provide tag structure, so any tag relationships become lost.

it's more convenient to see the title, body and then the less important metadata

This is very true when editing the files directly, but the front matter is wrapped in {}, so can easily be folded away. As for the app to read the files, the front matter data is so small that it won't have a negative effect. There are more and more parser libraries adding support for front matter which in time may alleviate the work you have to maintain going forward.

Either way, great work on what you've achieved here. There are a lot of promising notes apps coming up and I'm excited to see this space evolve.

@NGenetzky

This comment has been minimized.

Copy link

commented Jan 4, 2019

For those who find them self here I thought I would mention that I did actually pursue supporting JoplinDb style of front matter using python-frontmatter. I got pretty far with it, but its unlikely the author of that library would accept a PR for the support even if I did get it prettied up.

Here is the branch: joplin-support

@laurent22

This comment has been minimized.

Copy link
Owner

commented Jan 5, 2019

@NGenetzky, perhaps if I create a spec for the ENEX format, the author of python-frontmatter would accept the PR?

@NGenetzky

This comment has been minimized.

Copy link

commented Jan 5, 2019

To be clear, I implemented a Handler for the Joplin style markdown, which contains content + "frontmatter" (which is ironically in the back of the file contents).

If you know python and regexp then its pretty easy to understand. It uses the YAML parser to parse the metadata, but separating the metadata from the rest of the document is a little ugly because it relies on "id" being the first key and "type_" being the last key.

All in all, I would probably be willing to pretty that Handler up if other people would use it, but thats just one of the very very many frontmatter parsing libraries out there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.