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?
Currently the first line of a draft is considered the title.
You can control exactly how the content is being passed out of Drafts via actions. What exactly is your set-up?
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
- add a meta block from the second line (title first)
- append a meta block at the bottom
- organize the meta data in a separate file (use @sylumer TADpole library from action directory for that)
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.
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.
Ok, after reading the pandoc documentation, I assume you are talking about this topic:
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
Right. Metadata would be a good example of something to treat differently from Title and Body Text.
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.
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:
- 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.
The only place I’ve seen it in relation to the currently supported flavours of Markdown for Drafts is in the MMD spec.
I’m tending to include MMD extensions - otherwise I couldn’t do tabular slides (often converted from CSV via mdpre) or footnotes.
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.
You may think about writing it with a hash and preprocess it before conversion with pandoc.
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.
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.
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.
There are other options for that too
@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.
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.
I don’t know if the roadmap has change in the interim, but that’s certainly where we’re starting from.
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.