It would be great as a lot of my note taking is script based & the use of Notes etc has been soul crushing! If there is any way to at least add a YAML<>JSON converter action it would be amazing!
Thanks for all of the great work! The app seems limitless, and I have had a great time converting over!
I second this — some inbuilt way to use YAML would be great, especially since as far as I can tell, MultiMarkdown header material looks like it can be interpreted as YAML.
I suggest converting drafts content could be done with a scripted action.
Do you want to write YAML and generate JSON or the other way arround?
Could you give a short overview of your workflow?
Should this be available on macOS or on iOS or both?
A draft metadata object - populated by either YAML or Markdown metadata - would be lovely. Bonus points for a body-after-metadata method on the draft object.
This would make a great action. Many wikis and static site generators support YAML front matter; the Marked 2 viewer does as well. I routinely put front matter into my (Multi) Markdown documents to provide date, version, copyright etc. I currently do this with Text Expander, but filling in the metadata from Drafts would be a big timesaver.
My template Multimarkdown YAML front matter below. It’s easy to see where Drafts metadata could fit, e.g., title, date, tags. (Ignore the random quote marks at the beginning and end - block quoting the example rendered without line breaks.)
“—
title:
author: David Lounsbury
date: 2020-09-14
affiliation: Mycorp
copyright: ©2020, Mycorp LLC
version: 0.1
tags:
—“
totally cool idea. this is really easy.
I will take a look at that
is this in an import scenario like a bulk import or file import?
Don’t be fooled into thinking YAML is just a single level of key value pairs. The v1.2 spec is probably more complex than most people might first imagine.
True, and use of YAML in e.g. AsciiDoc spines can get very complex. However, an action that covers the Markdown front matter I mentioned or @martinpacker ‘s draft metadata case would be a good first step. I’d definitely use it nearly daily.
@sylumer you are right. implementing the full specification is hard.
But the front matters typically are very simple I first would stick to the example from @technodad which are only simple key, values except the tag section.
Am I wrong?
My idea is to do the more complex stuff from python3 and use the pyyaml module. That should implement the full speficiation. A draft java script could add a front matter or back matter from the drafts meta data and a json config file in the iCloud directory of drafts.
I started to modify the bulk import markdown script from @gcaprio here https://github.com/42sol-eu/drafts_pro/tree/setup/_scripts
@technodad / @martinpacker are you using any spefic tools (Hugo, Jekyll)?
It’s much more manual than that, I’m afraid. My top workflows are publishing short Multimarkdown documents (e.g. meeting minute) in HTML using Drafts 2, and creating wiki pages in GitLab-flavor Markdown.
No. Just typing metadata lines.
Just curious: Is the YAML use case Ansible playbooks? (Happen to be on a call where this is being discussed.)
not for me. I do have two very good DevOp Guys in my company and shying away from Infrastructure.
But I think ansible playbooks might become a bit difficult- hence they are nested more layers - as far as I remember.
I think it is simple to do in relatively flat key value stores crating variables for an processing engine (like hugo)
My primary aim is to support document variables like in asciidoctor. I just realised today that the missing variable definition is the reason for front matters in markdown.
I am on the edge of adding front and back matter from drafts meta data on the markdown bulk import python script.
After that I would do some script in Java Script to provide some actions like:
Any one with more ideas
Yes, I agree that YAML for Ansible is thoroughly nested. And that’s where the JSON hierarchical/tree approach makes sense.
It occurs to me that if @agiletortoise did this metadata parsing he’d be best off with a good quality open source library. (Assuming such a thing exists in a form that Drafts can use.)
On the Markdown metadata front I have code that takes Markdown and turns it into Powerpoint using python-pptx. (It won’t run on iOS, though.) That same Markdown can, of course, be used elsewhere. Including as a draft. Some aspects of my code’s processing are controlled by metadata. For example, the title page main font size.
I might well want to:
In either case a metadata object would be handy.
(Yes, I hope to open source my code this year. But that’s not the point of this comment.)
great stuff. maybe we could define a meta object file with the same title or connect it via the drafts uuid.
if we define a simple structure in json/yaml we could even connect many drafts to one meta data object.
that would play nicely with the zettelkasten approach of simple thoughts in one draft as well as a larger draft (like an article or blog)
In case it is of any use, take a look at the TA_meta* functions in the TADpoLe library. They are used for storage and retrieval of persistent custom meta data for a draft. It adds a meta property to a draft which you can then add any sub property to that you like.
By way of example.
If you include the TADpoLe library and run the following on a draft,
draft.TA_metaRead();
alert(draft.meta.foo);
draft.meta.foo = "bar";
alert(draft.meta.foo);
draft.meta.foo = "quz";
draft.TA_metaWrite();
On the first run it will alert undefined and then bar.
On subsequent runs it will alert quz then bar.
That’s a really useful contribution, @sylumer.
The question is whether metadata function should be “pushed down” into Drafts itself. For well-formed function my bias would be towards “yes” on that one.