managing entities
I've got an mmd document that contains angle brackets. MMC appears to assume that I'll enter them bare, and converts them to html entities on export/preview. However, I also want to paste the md source into a GitHub wiki in md format, and it expects (consistent with Markdown documentation) that the angles are already encoded in the source.
Is there a way to accomplish this? If not, I suggest a copy-as option that handles escapes appropriately.
Related question: how to have an escaped vertical bar in a table; right now the backslash shows up in the preview. Related to that, should the table editing logic be interpreting pipes that are not set off by spaces as table cell separators?
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 11 Dec, 2013 10:51 PM
I'm not sure I follow you.
It sounds like you want to copy the raw source, but also have it converted to HTML at the same time? Composer can easily do both separately, but I'm not sure how to copy both at the same time.
As for your table question, if you escape a vertical bar in a table, the pipe is properly escaped and the slash does not appear (`\|`). MMD does not require that pipes be space separated inside table cells to be recognize.
Fletcher
2 Posted by jlundell on 11 Dec, 2013 11:05 PM
No. I want Markdown source that I can paste elsewhere as Markdown source. But Markdown expects that angle brackets (and ampersands) as html entities, not as literal characters. Composer deviates from that, which ordinarily is a Good Thing, much more readable. But not portable.
Pipes: see attached example.
Support Staff 3 Posted by Fletcher on 11 Dec, 2013 11:23 PM
1) Markdown doesn't expect that angle brackets/ampersands are html entities. It's specifically designed to allow you to use them as literal characters, and will convert them to entities where appropriate when you create HTML. Sounds like your problem is on the other end. If you give me a specific example, I can try and help but MultiMarkdown handles `<`, `>`, and `&` the same way that Markdown does.
2) Your pipes are inside code spans.
F-
--
Fletcher T. Penney
Manager, Founder
MultiMarkdown Software, LLC
[email blocked]
4 Posted by jlundell on 11 Dec, 2013 11:34 PM
1) I stand corrected. I'll file a bug at GitHub.
2) OK, but if I apply "Format->Clean up selected table" to that table, Composer treats them as cell separators, even though they're in code spans. That's what led me to think I need to escape them.
Support Staff 5 Posted by Fletcher on 11 Dec, 2013 11:41 PM
Ahhh…. So what you really meant to tell me was that you think there's a bug in the table cleanup logic… ;)
Yes. That routine uses regexp to clean up, which is separate from actually parsing. I'll look into it.
F-
--
Fletcher T. Penney
Manager, Founder
MultiMarkdown Software, LLC
[email blocked]
6 Posted by jlundell on 12 Dec, 2013 12:16 AM
Now I know that. Thanks for your help. Hopefully GitHub will be as responsive...
(BTW, I've had Composer installed for a while now, but this is the first time I've really tried to use it. I wanted to generate some API docs that would be heavy on code fragments and tables, and there aren't a lot of good alternatives. So far so good!)
Support Staff 7 Posted by Fletcher on 12 Dec, 2013 06:35 PM
Glad it's working well for you. You will have to be careful out "cleaning up" tables that include pipes, but if you create the table inside Composer, all should be well.
Fletcher closed this discussion on 12 Dec, 2013 06:35 PM.
jlundell re-opened this discussion on 16 Dec, 2013 04:12 PM
8 Posted by jlundell on 16 Dec, 2013 04:12 PM
On digging a little deeper, I think I've pinned down what's going on. It comes down to an apparent difference in how Markdown and MultiMarkdown define html tags. Gruber wrote, "if you use angle brackets as delimiters for HTML tags, Markdown will treat them as such".
This ends up being ambiguous, because he never bothers to say exactly what he means by "HTML tags". The Perl implementation, though, has this:
> # Encode naked <'s
> $text =~ s{<(?![a-z/?\$!])}{<}gi;
(My Perl is a little rusty, but that character class looks just a little odd to me.)
My doc had this: "<device>:<os_version>". MultiMarkdown treats <device> as an HTML tag, but not <os_version>; Markdown treats them both as tags. I didn't look up the PEG syntax for an HTML tag, but it seems obvious what's going on.
Support Staff 9 Posted by Fletcher on 16 Dec, 2013 05:31 PM
Gruber's version is much less specific about what might be an HTML tag. It therefore allows the underscore to be considered an HTML tag, even though I don't think there are any HTML tag names containing underscores.
MacFarlane's peg-markdown was more specific, so it recognizes that `os_version` is definitely not an HTML tag, so it gets converted to entities. MultiMarkdown's parser is related to peg-markdown's, so that behavior persists.
In either case, MultiMarkdown will allow you to use entities without a problem.
F-
Fletcher closed this discussion on 23 Dec, 2013 03:38 PM.