tag:support.multimarkdown.com,2013-02-12:/discussions/problems/689-managing-entitiesMultiMarkdown Software, LLC: Discussion 2013-12-23T16:08:49Ztag:support.multimarkdown.com,2013-02-12:Comment/305067162013-12-11T22:51:20Z2013-12-11T22:51:20Zmanaging entities<div><p>I'm not sure I follow you.</p>
<p>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.</p>
<p>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
(<code>\|</code>). MMD does not require that pipes be space
separated inside table cells to be recognize.</p>
<p>Fletcher</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/305067162013-12-11T23:05:39Z2013-12-23T16:08:48Zmanaging entities<div><p>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.</p>
<p>Pipes: see attached example.</p></div>jlundelltag:support.multimarkdown.com,2013-02-12:Comment/305067162013-12-11T23:23:45Z2013-12-11T23:23:45Zmanaging entities<div><p>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 <code><</code>,
<code>></code>, and <code>&</code> the same way that
Markdown does.</p>
<p>2) Your pipes are inside code spans.</p>
<p>F-</p>
<h2><a href="#" name="" class="anchor"></a></h2>
<p>Fletcher T. Penney<br>
Manager, Founder<br>
MultiMarkdown Software, LLC<br>
<a href=
"mailto:admin@multimarkdown.com">admin@multimarkdown.com</a></p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/305067162013-12-11T23:34:48Z2013-12-23T16:08:48Zmanaging entities<div><p>1) I stand corrected. I'll file a bug at GitHub.</p>
<p>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.</p></div>jlundelltag:support.multimarkdown.com,2013-02-12:Comment/305067162013-12-11T23:41:37Z2013-12-11T23:41:37Zmanaging entities<div><p>Ahhh…. So what you really meant to tell me was that you
think there's a bug in the table cleanup logic… ;)</p>
<p>Yes. That routine uses regexp to clean up, which is separate
from actually parsing. I'll look into it.</p>
<p>F-</p>
<h2><a href="#" class="anchor" name=""></a></h2>
<p>Fletcher T. Penney<br>
Manager, Founder<br>
MultiMarkdown Software, LLC<br>
<a href=
"mailto:admin@multimarkdown.com">admin@multimarkdown.com</a></p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/305067162013-12-12T00:16:03Z2013-12-23T16:08:49Zmanaging entities<div><p><em>Now</em> I know that. Thanks for your help. Hopefully GitHub
will be as responsive...</p>
<p>(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!)</p></div>jlundelltag:support.multimarkdown.com,2013-02-12:Comment/305067162013-12-12T18:35:24Z2013-12-12T18:35:24Zmanaging entities<div><p>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.</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/305067162013-12-16T16:12:06Z2013-12-23T16:08:49Zmanaging entities<div><p>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".</p>
<p>This ends up being ambiguous, because he never bothers to say
exactly what he means by "HTML tags". The Perl implementation,
though, has this:</p>
<blockquote>
<p># Encode naked <'s $text =~
s{<(?![a-z/?\$!])}{<}gi;</p>
</blockquote>
<p>(My Perl is a little rusty, but that character class looks just
a little odd to me.)</p>
<p>My doc had this: ":". MultiMarkdown treats as an HTML tag, but
not ; 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.</p></div>jlundelltag:support.multimarkdown.com,2013-02-12:Comment/305067162013-12-16T17:31:58Z2013-12-16T17:31:58Zmanaging entities<div><p>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.</p>
<p>MacFarlane's peg-markdown was more specific, so it recognizes
that <code>os_version</code> 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.</p>
<p>In either case, MultiMarkdown will allow you to use entities
without a problem.</p>
<p>F-</p></div>Fletcher