[Pending] Pandoc Title / Metadata support

[ifischer]

Currently the first line of a draft is considered the title.
If that line starts with a “#”, it is assumed to be stripped.
In some Markdown — like Pandoc — a title can be in a metadata block, with lines starting with “%” and the first line being the title.
Can we treat % at the start of the first line as the title, and strip it the same way H1 / “#” is stripped?

[sylumer]

You can control exactly how the content is being passed out of Drafts via actions. What exactly is your set-up?

[Andreas_Haberle]

Drafts always sets the first line as a title.

We had a discussion some weeks ago about managing meta data in drafts.

The three approaches in short

1. add a meta block from the second line (title first)
2. append a meta block at the bottom
3. organize the meta data in a separate file (use @sylumer TADpole library from action directory for that)

[ifischer]

I wasn’t referring to how it was being passed out of Drafts, so much as a requested change in how Drafts interprets that first line as a title.

[sylumer]

@ifischer

Currently the first line of a draft is considered the title.
If that line starts with a “#”, it is assumed to be stripped.

Just as some context, the reason I had taken it as you were talking about exporting is because the first line of the draft in Drafts is defined as the title, but I didn’t think that the second line was true.

There are some places where what is effectively a display version of the title is used, such as in the draft listing for example, but whenever the title property of a draft is accessed, in my experience, it has always included any leading Markdown heading syntax that is specified.

Obviously an incorrect assumption on my part, but just explaining the why.

[Andreas_Haberle]

Ok, after reading the pandoc documentation, I assume you are talking about this topic:

Metadata blocks

Extension: pandoc_title_block

If the file begins with a title block

% title
% author(s) (separated by semicolons)
% date

As long as the title stays in the first line it should not be so hard to add % to the signs that get removed.
@agiletortoise … am I wrong?

I hope this feature will be controlled by the upcoming syntax definition extension in Drafts.
Because it is very convenient to remove this heading characters in the other parts of the app

[martinpacker]

Right. Metadata would be a good example of something to treat differently from Title and Body Text.

[sylumer]

Title is positional, but such meta data is not in that while it does always appear at the start, the length varies.

In this particular case,it seems to be tied to a specific syntax - Specifically Pandoc’s own flavour of Markdown. Like Andreas suggested, it seems to be more of a flavour of syntax.

Maybe Drafts could offer more control around this sort of thing, but it seems prudent to also consider what the custom syntax definitions will bring.

Perhaps tying in the display title in Drafts to the syntax definition. I happen to be of the opinion that if a draft is set as plain text and the title starts with a hash, the title listed in the Drafts list should also start with a hash as it is only formatting if you are dealing with Markdown.

[martinpacker]

I realise this is an immodest proposal - and I (and probably @Andreas_Haberle) have an ulterior motive - md2pptx.

I would like the data model to have another component, so that we have three:

1. Title
2. Metadata
3. Body text

How metadata is handled and displayed is the interesting bit. Also interesting is how the title is detected and displayed - as it might not be the first line of the draft.

What I’m not sure about is whether metadata key/value pairs is part of what passes for the Markdown spec.

[sylumer]

@martinpacker

What I’m not sure about is whether metadata key/value pairs is part of what passes for the Markdown spec.

The only place I’ve seen it in relation to the currently supported flavours of Markdown for Drafts is in the MMD spec.

https://fletcher.github.io/MultiMarkdown-4/metadata.html

[martinpacker]

I’m tending to include MMD extensions - otherwise I couldn’t do tabular slides (often converted from CSV via mdpre) or footnotes.

[Andreas_Haberle]

@sylumer

I happen to be of the opinion that if a draft is set as plain text and the title starts with a hash, the title listed in the Drafts list should also start with a hash as it is only formatting if you are dealing with Markdown.

That’s right. It is a special feature that only works on the markdown heading style.

In Java Script it does not remove the comments.

@ifischer
You may think about writing it with a hash and preprocess it before conversion with pandoc.

@sylumer

Maybe Drafts could offer more control around this sort of thing, but it seems prudent to also consider what the custom syntax definitions will bring.

I think that would be great to have a toggle switch to strip the corresponding header signs.

If you look into other syntax definitions like DokuWiki it even would have to remove the signs from start and stop of the line.

A logical way would be to tie it to the syntax definition.

@martinpacker

• Title
• Metadata
• Body text

I would like to have a metadata block in drafts that is foldable and merges the (i) section metadata with user defined key/value pairs.

This would be a completely different UI and I am not sure how @agiletortoise would think about it.

A more simpler solution would be to invert the title colors to show its special meaning.

[martinpacker]

You are thinking of presentation / editing of metadata. I agree that’s a new UI. I’m also thinking of a metadata object as an attribute of a draft - a list of key/value pairs. One thing I notice, BTW, is metadata can be multiline - according to the MultiMarkdown spec.

[sylumer]

@martinpacker

I’m also thinking of a metadata object as an attribute of a draft - a list of key/value pairs

There are other options for that too

Calling an action after setTemplateTag (bug with app.queueAction)

You could store them as metadata using the functions I wrote into the TADpoLe library. They store the data outside of the draft so as not to pollute the existing content or meta data (e.g. tags). Once you include the library (including the TAD action from the ThoughtAsylum Action group (download it and run the refresh action as per the instructions to get the latest library file on your devices) you can then call the meta data functions. draft.TA_metaRead() will initialise the current draft w…

[Andreas_Haberle]

@sylumer that’s a great function.

But it is still not closely linked to the draft itself.

This is moving from the original topic but I think that the title field itself is not obvious in the actual implementation and that the metadata could be extended inside DraftsCore implementation.

In the current version everything is a big textedit and a view behind the info button.

I would love to see a new implementation that merges the given implementation with the new ideas.

It might be not so easy to get the easy and lightweight editor with a more complex implementation but let’s say it @agiletortoise is one of the iOS developers - so I think he would be able to do this magic in Drafts.

[sylumer]

@Andreas_Haberle

But it is still not closely linked to the draft itself.

Well it is linked to the UUID, so that’s more than close in my book.

For discussions on meta data, it may be worth going back through other discussions too. There have been a few over the years! Custom meta data in particular has come up a few times and Greg’s previous proposed solution was actually to use a second draft and some actions to tie the meta data block to the original draft.

Option of having a comment section to the right with synopsis and general comments (meta text)

One important feature I miss in Drafts is the option of having a section/column in the right corner where you can enter metatext such as a little synopsis about what this particular note is about and general comments / TO DO’s, and so on. If implemented, then it would be possible to only have the real text in the actual note (and not like now where we have to blend the real text and meta-text and TO-DO’s together in the same note). If this feature was implemented, I’d surely sign up for Drafts…

I don’t know if the roadmap has change in the interim, but that’s certainly where we’re starting from.

[martinpacker]

Thank you. Actions is a good way to do it. However, I think there are advantages in it being pushed down into “the engine” - as we Db2 fans like to call it.