Meta data or comment later in document
I'm struggling with how to add what I call "consistency notes" inside my novel. 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.
How do I accomplish this sort of thing? I was excited at first to read about meta data tags, but those can only occur at the top of a file. While great, the limitation is a killer. Even tracking point of view would be limiting. What if there is a shift? One would want to note that.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Fletcher on 05 Jun, 2018 10:32 PM
There are several ways to store notes in your document:
CriticMarkup provides a syntax for notes --
{>>foo<<}-- You'll have to pay attention to the CriticMarkup preferences to control whether notes are printed/exported or stripped out.You can also use HTML comments --
<!--foo-->(these will be present in the source if you export to HTML, but not visible if you print the preview)Fletcher
2 Posted by Rolf on 06 Jun, 2018 12:17 AM
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.
Since posting, I found this:
https://stackoverflow.com/questions/4823468/comments-in-markdown
Looks like I'm not alone... ;^|
Support Staff 3 Posted by Fletcher on 06 Jun, 2018 10:13 PM
What do you want the key value pairs to do?
4 Posted by Rolf on 06 Jun, 2018 11:42 PM
I started off with that:
"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."
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.
Support Staff 5 Posted by Fletcher on 07 Jun, 2018 12:17 AM
No - why do they need to be key value pairs instead of comments? What is your expected behavior?
Sent from my iPhone
6 Posted by Rolf on 07 Jun, 2018 12:34 AM
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.
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.
Rolf closed this discussion on 07 Jun, 2018 12:35 AM.
Fletcher re-opened this discussion on 07 Jun, 2018 12:38 AM
Support Staff 7 Posted by Fletcher on 07 Jun, 2018 12:38 AM
But why does it matter? Why can't you put your information as a comment?
{>>datetime="7 Jun...."<<}
If you're not expecting something to be done with the data (e.g.
processed into a database in some way), then it doesn't matter what the
content of the comment is, or what format it is (other than avoiding
empty lines within comments.)
Just pretend that {>><<} means metadata, and you're golden.
;)
F-
8 Posted by Rolf on 07 Jun, 2018 12:40 AM
The second line in my original post was:
"These are really useful for use with scripts that can run over a larger text looking for alignment with other plot threads."
Support Staff 9 Posted by Fletcher on 07 Jun, 2018 12:43 AM
I guess I don't understand why your scripts can't use {>><<}?
Obviously -- do what works for you. But so far I haven't heard anything that can't be appropriately done with the current options.
But use the tools that work best for you.
F-
Rolf closed this discussion on 07 Jun, 2018 12:44 AM.
Rolf re-opened this discussion on 07 Jun, 2018 12:50 AM
10 Posted by Rolf on 07 Jun, 2018 12:50 AM
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.
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.
Rolf closed this discussion on 07 Jun, 2018 12:54 AM.
Fletcher re-opened this discussion on 07 Jun, 2018 12:57 AM
Support Staff 11 Posted by Fletcher on 07 Jun, 2018 12:57 AM
It's CriticMarkup, which is part of MultiMarkdown (has been since
shortly after they released CriticMarkdown. I was able to give some
feedback during their initial testing and liked (most of) their ideas.
So I put it in MMD as well as Composer).
So it is not supported by all Markdown implementations. But it is
supported by all MultiMarkdown tools, unless they don't actually support
MultiMarkdown. In which case they should use a different name.
You're correct that I will probably not add metadata later in the
document (would require a different syntax since there would be too many
false positives with the current syntax.)
My point is that you don't need me to add something for you. What you
need seems to already exist, it just has a different name.
12 Posted by Rolf on 07 Jun, 2018 01:20 AM
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.
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.
Though, I can appreciate the complication it would add to allow your current meta approach later in the document.
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.
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.
Support Staff 13 Posted by Fletcher on 08 Jun, 2018 02:01 PM
Composer has additional features, but the parsing engine itself is kept
in sync with the official MultiMarkdown parser. So anything I add to
MMD gets added to Composer automatically.
I can understand difficulty with convincing an editor to use
CriticMarkup, but they would have to ignore any custom markup you add.
Regardless of what syntax you use.
You're welcome to use fenced code blocks if you like. And again, you
don't need anything special from me to make it happen.
```{=ignore}
foo:bar
```
The MultiMarkdown-6 QuickStart guide describes this syntax:
<https://github.com/fletcher/MultiMarkdown-6/>
Yes -- there are occasionally things that would have to be officially
added to MultiMarkdown. But there are a *lot* of things that users can
do on their own without me changing things.
Fletcher
Fletcher closed this discussion on 26 Sep, 2018 02:20 PM.