tag:support.multimarkdown.com,2013-02-12:/discussions/questions/5425-meta-data-or-comment-later-in-documentMultiMarkdown Software, LLC: Discussion 2018-09-26T14:20:24Ztag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-05T22:32:40Z2018-06-05T22:32:40ZMeta data or comment later in document<div><p>There are several ways to store notes in your document:</p>
<ul>
<li>
<p>CriticMarkup provides a syntax for notes -- <code>{>>foo<<}</code> -- You'll have to pay attention to the CriticMarkup preferences to control whether notes are printed/exported or stripped out.</p>
</li>
<li>
<p>You can also use HTML comments -- <code><!--foo--></code> (these will be present in the source if you export to HTML, but not visible if you print the preview)</p>
</li>
</ul>
<p>Fletcher</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-06T00:17:54Z2018-06-06T00:17:54ZMeta data or comment later in document<div><p>Actually, I want more than notes, but that would be a start. Ulysses has support for this in Markdown XL, which I thought was pretty basic, but it turns out it's not. Basically, I'm looking to use meta data anywhere in the document, or less desirably imbed sections that contain key value pairs that do not export.</p>
<p>Since posting, I found this:<br>
<a href="https://stackoverflow.com/questions/4823468/comments-in-markdown">https://stackoverflow.com/questions/4823468/comments-in-markdown</a></p>
<p>Looks like I'm not alone... ;^|</p></div>Rolftag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-06T22:13:28Z2018-06-06T22:13:28ZMeta data or comment later in document<div><p>What do you want the key value pairs to do?</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-06T23:42:19Z2018-06-06T23:44:35ZMeta data or comment later in document<div><p>I started off with that:</p>
<p>"For example, marking time passage and location shifts within a scene. These are really useful for use with scripts that can run over a larger text looking for alignment with other plot threads. This is content that would never be a part of the final output document, but is context for the document."</p>
<p>I would add that it's also positionally critical. Making those notes at the top of a file is useless as they change over the length of the work. Splitting a file just to make a time or place note is also awkward at best as a scene is defined by neither of these reliably.</p></div>Rolftag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-07T00:17:10Z2018-06-07T00:17:10ZMeta data or comment later in document<div><p>No - why do they need to be key value pairs instead of comments? What is your expected behavior?</p>
<p>Sent from my iPhone</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-07T00:34:51Z2018-06-07T00:34:51ZMeta data or comment later in document<div><p>Okay… I thought that would be clear. But I mean that to mark the passage of time as a variable would be ideal. E.g. datetime=“7 Jun 10:21:15 2018”, or whatever. I said above that a comment would work, but not as well. It’s not a comment after all—at least not editorially as in Critic Markup. It's metadata that is positionally relevant within a scene.</p>
<p>I get the vibe though that markdown and multimarkdown as standards are, for some reason, against this sort of thing. I plan to keep up with your work and app, but I think I need to get back to writing, and for me it seems clear that means back to Ulysses or Scrivener.</p></div>Rolftag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-07T00:38:05Z2018-06-07T00:38:05ZMeta data or comment later in document<div><p>But why does it matter? Why can't you put your information as a comment?</p>
<pre>
<code>{>>datetime="7 Jun...."<<}</code>
</pre>
<p>If you're not expecting something to be done with the data (e.g.<br>
processed into a database in some way), then it doesn't matter what the<br>
content of the comment is, or what format it is (other than avoiding<br>
empty lines within comments.)</p>
<p>Just pretend that {>><<} means metadata, and you're golden.</p>
<p>;)</p>
<p>F-</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-07T00:40:54Z2018-06-07T00:43:54ZMeta data or comment later in document<div><p>The second line in my original post was:</p>
<p>"These are really useful for use with <strong>scripts</strong> that can run over a larger text looking for alignment with other plot threads."</p></div>Rolftag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-07T00:43:34Z2018-06-07T00:43:34ZMeta data or comment later in document<div><p>I guess I don't understand why your scripts can't use {>><<}?</p>
<p>Obviously -- do what works for you. But so far I haven't heard anything that can't be appropriately done with the current options.</p>
<p>But use the tools that work best for you.</p>
<p>F-</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-07T00:50:31Z2018-06-07T00:50:31ZMeta data or comment later in document<div><p>For starters, unless mistaken, that is Critic Markdown, not MultiMarkdown, so any tool that doesn't support Critic Markdown will not ignore it. Right? Critic Markdown is far from widely adopted.</p>
<p>I'm making what I think is a valid case for meta data tags, that are already in the standard, being allowed later in the document for relevant reasons. I'll stop trying though now.</p></div>Rolftag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-07T00:57:20Z2018-06-07T00:57:20ZMeta data or comment later in document<div><p>It's CriticMarkup, which is part of MultiMarkdown (has been since<br>
shortly after they released CriticMarkdown. I was able to give some<br>
feedback during their initial testing and liked (most of) their ideas.<br>
So I put it in MMD as well as Composer).</p>
<p>So it is not supported by all Markdown implementations. But it is<br>
supported by all MultiMarkdown tools, unless they don't actually support<br>
MultiMarkdown. In which case they should use a different name.</p>
<p>You're correct that I will probably not add metadata later in the<br>
document (would require a different syntax since there would be too many<br>
false positives with the current syntax.)</p>
<p>My point is that you don't need me to add something for you. What you<br>
need seems to already exist, it just has a different name.</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-07T01:20:38Z2018-06-07T01:20:38ZMeta data or comment later in document<div><p>Thank you for the clarification. It is good to know that Critic Markup is part of the standard—that wasn’t clear to me. I though it was just that your app supported it.</p>
<p>It still feels like a hack to use something intended as a comment from an editor as a splat of JSON key value pairs or whatever. But it would work. That said, I would have enough challenge getting an editor to use Critic Markup at all, and when they saw those bits, they would panic. I’d have the challenge of stripping them out so they could use the {>><<} tag. Plus the added challenge of keeping them separate after getting feedback from said editor. I don’t currently use Critic Markup, but I can see this as a looming problem if I took your advice and then tried use it with an editor.</p>
<p>Though, I can appreciate the complication it would add to allow your current meta approach later in the document.</p>
<p>Here’s an idea. What if you supported a version of fenced code blocks that were ignored like a comment? Then a human would know to ignore them, scripts could use them, and output documents would not have them. And there would be no added complication to meta data like how to handle changing values.</p>
<p>I wasn’t being petty, about going back to Ulysses or Scrivener. They just better fit at least my kind of long form writing. But I really do like your app, and will keep trying it out as you add to it.</p></div>Rolftag:support.multimarkdown.com,2013-02-12:Comment/454158552018-06-08T14:01:16Z2018-06-08T14:01:16ZMeta data or comment later in document<div><p>Composer has additional features, but the parsing engine itself is kept<br>
in sync with the official MultiMarkdown parser. So anything I add to<br>
MMD gets added to Composer automatically.</p>
<p>I can understand difficulty with convincing an editor to use<br>
CriticMarkup, but they would have to ignore any custom markup you add.<br>
Regardless of what syntax you use.</p>
<p>You're welcome to use fenced code blocks if you like. And again, you<br>
don't need anything special from me to make it happen.</p>
<pre>
<code>```{=ignore}
foo:bar
```</code>
</pre>
<p>The MultiMarkdown-6 QuickStart guide describes this syntax:</p>
<p><a href="https://github.com/fletcher/MultiMarkdown-6/">https://github.com/fletcher/MultiMarkdown-6/</a></p>
<p>Yes -- there are occasionally things that would have to be officially<br>
added to MultiMarkdown. But there are a <em>lot</em> of things that users can<br>
do on their own without me changing things.</p>
<p>Fletcher</p></div>Fletcher