Thoughts about the future of MMD
Fletcher T. Penney
interviewed about MMD on the Mac Power Users podcast (should come out
this weekend), I had a little bit of free time, and I looked again at
C implementations of Markdown. This has prompted me to think about
where MMD is, and where it's going.
# MultiMarkdown, the syntax #
Overall, I am pretty happy with the MMD syntax. I think the table
syntax is a horrible kludge. No one else (to my knowledge) has
anything better. What I would really like to is to blend [elastic
tabstops](http://nickgravgaard.com/elastictabstops/) with a MMD table
syntax. This would be very easy (simply tab to indicate a new
column), and elegant, and visually appealing, but would require an
editor that understood elastic tabstops, or a routine to properly
space the columns. I haven't given up on this, but am not sure
exactly what the future holds for the table syntax.
I wonder about the necessity of the ASCIIMathML feature. I use it
infrequently, but it seems nice. The problem is that I think most of
the heavy math users just use raw LaTeX.
Otherwise, I think the syntax more or less has everything it needs to,
keeping in mind that the goal is to remain simple and easy to read,
*not* to implement every feature under the sun.
Recent trends would seem to suggest many others agree - my twitter
searches and google alerts are continuing to show more and more
"chatter" about MMD, which is nice. While not necessarily my original
goal, it is seeming to become the Markdown flavor of choice for
writers. I can work with that.
# MultiMarkdown, the program #
Perl is easy. Perl is well-supported. Perl is not super-fast. Perl
is not available on iPhone.
I'm wondering if the Perl implementation is beginning to reach it's
limits. Longer documents can be quite slow to process with the perl
script. Installation on Windows is a bit painful.
So I started looking at C implementations of markdown. I am being
drawn towards peg-markdown. Though I don't know much at PEG's, they
seem like an interesting idea that should be more rigorous and less
error prone than a maze of regular expressions. And it's performance
on longer documents is *MUCH* better. Additionally, since it becomes
compiled as a C library, I *think* it could be made to function on an
iOS device. This could open up the ability to process MultiMarkdown
documents into other formats on the device. (Keep in mind that the
holy grail of converting MMD->LaTeX->PDF will probably not happen - I
for one am not going to try and maintain a TeX implementation on the
iphone....)
I have started a github project to try and convert peg-markdown into
peg-multimarkdown. It's only a couple of days in, but a couple of
features are starting to make their way over. Some features will be
easier than others. I haven't decided what to do about the XSLT files
- those may stay outside the core MMD program, much like they do now.
The metadata matching is giving me some trouble at the moment, so it's
now a separate branch as I try to figure it out.
# What I need #
What I need is feedback. Thoughts about pros and cons of migrating to
a C project. For example, this would mean I would probably need help
being sure it compiles properly on different hardware, and how to
properly package it so that it can be easily downloaded by the less
computer savvy(with necessary libraries - e.g. glib2).
A big con would be that it might be harder for those wishing to
customize their own version of MMD (though the perl version would
still be around).
Another would be that in the unlikely event Gruber ever modified the
canonical Markdown, those changes would have to be entirely recoded
into the PEG and c-code. A risk I am probably willing to take.
Also, I am using this as an opportunity to revisit the syntax and
default output (XHTML). I've already made a slight change to the way
footnotes are output. But this is time to improve things where
possible.
Most importantly, I welcome any ideas about tables. Remember - the
goal is not to support every sort of table out there, but rather a
simple, easy to read format that covers *most* tables. Multicolumn
cells are acceptable, but I am really unlikely to go for a syntax that
supports multi-row cells unless it's extremely elegant.
Also, any thoughts on whether a central repository for sharing XSLT
files would be useful. I don't have much of any idea how many are out
there. I think most of the changes are slight tweaks to existing
XSLTs, but I certainly want to make it easy to share if anyone is
interested.
For those who are so inclined, check out the peg-multimarkdown fork:
https://github.com/fletcher/peg-multimarkdown
And don't forget the new MMD Wiki:
https://github.com/fletcher/MultiMarkdown/wiki
Thanks!
Fletcher
--
Fletcher T. Penney
flet...@fletcherpenney.net
TJ Luoma
<flet...@fletcherpenney.net> wrote:
> # MultiMarkdown, the syntax #
>
> Overall, I am pretty happy with the MMD syntax. I think the table
> syntax is a horrible kludge. No one else (to my knowledge) has
> anything better. What I would really like to is to blend [elastic
> tabstops](http://nickgravgaard.com/elastictabstops/) with a MMD table
> syntax. This would be very easy (simply tab to indicate a new
> column), and elegant, and visually appealing, but would require an
> editor that understood elastic tabstops, or a routine to properly
> space the columns. I haven't given up on this, but am not sure
> exactly what the future holds for the table syntax.
The table syntax reminds me of a quote from ¿Churchill? who said
"Democracy is the worst form of government except all of the others"
(paraphrased).
Every time I try to think about a better way to mark up tables, I come
up with basically what you have.
Elastic Tabstops sound like it brings at least as many problems as it solves.
TjL
Fletcher Penney
F-
> --
> You received this message because you are subscribed to the Google Groups "MultiMarkdown Discussion List" group.
> To post to this group, send email to multim...@googlegroups.com.
> To unsubscribe from this group, send email to multimarkdow...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/multimarkdown?hl=en.
>
Alan Schmitt
> I wonder about the necessity of the ASCIIMathML feature. I use it
> infrequently, but it seems nice. The problem is that I think most of
> the heavy math users just use raw LaTeX.
I confirm that for heavy math usage, I use raw LaTeX. In fact, I cannot even rely on the html comment escape mechanism, as some LaTeX I write (typically when I use xymatrix) needs to include "--", which breaks everything. In those cases, I "\input" the file I need in the MMD part and don't process the LaTeX file.
> Another would be that in the unlikely event Gruber ever modified the
> canonical Markdown, those changes would have to be entirely recoded
> into the PEG and c-code. A risk I am probably willing to take.
I don't expect Gruber to change the canonical Markdown, so it may be a small risk.
Thanks for your hard work on MMD, I find it more and more useful each day.
Alan
Sherwood Botsford
One of the 'bugs' of MMD, I consider to be a feature: <DIV> is a tag
and starts the process of ignoring content, but <div> is not. (Or
perhaps other ways around) This Bug/Feature allows me to either turn
off processing or not. The cost of this is slight violation of the
the xhmtl standard. Tags that are ignored are wrapped in <P> tags.
Of course I would prefer MMD to produce valid XHTML. DIV, IMHO, is a
generic container tag, and so should be passed through unchanged, but
the contents still processed.
Several MD variants have a flag you can put in the tag to do this.
For DIV, HEAD, BODY, and HTML my preference would be that the default
is to process the content, with a flag to NOT process it.
Having the DIV container option allows me have almost newsletter
formatting capability:
E.g.
<DIV class="pictureRight40">
link to picture
picture caption
</DIV>
The class pictureRight40 has the attributes in my CSS file to be 40%
of the width of the container, float on the right side of the page,
have a caption font that is distinct from the body text.
I can live with the present situation however. So far no browser
fusses over the extra <P> tags around the <DIV>'s
I also use this functionality to do pullquotes (A few words in very
large font, boxed, in the middle of the column) and sidebars. (An
aside giving further detail about something, with a somewhat different
style.)
***
The only other feature I really want is to be able to resolve links
to an external file.
Some links are used repeatedly on a web site. When you reorganize a
web site, it takes a while to track these down, and correct them.
My ideal behaviour would be as follows:
* The present link creation syntax is supported.
* If a link is not found in the document, the reference is matched
against a simple database. This could be at once extreme, just a flat
file with the structure reference | link path. Or it could be ndb,
or somthing larger.
Respectfully,
Sherwood of Sherwood's Forests
Sherwood Botsford
Sherwood's Forests -- http://Sherwoods-Forests.com
780-848-2548
50042 Range Rd 31
Warburg, Alberta T0C 2T0
Merlin
enough.
While I sing the praises of you and MMD every chance I get, I never
want it to go unsaid that my work (such as it is) and how I do it
wouldn't be possible without John and your work.
My main feedback has less to do specifically with MMD and more to do
with the wild west that my good friend John's seemingly abandoned real
estate is turning into. While I love the broad adoption and ambitious
features that all the various nephews of MD (I won't kill a page
naming them all) are bringing to us, I wonder if there's a risk to
having all these different flavors forking all over the place. It
feels like something that will eventually become damaging, divisive,
and bad for users and developers.
To wit, I suspect one reason JG is staying our of all this may be that
he considers MD:
1. done and feature-complete and
2. only harmed by features that make it less "simple"
That's just my guess, but as a fan of MMD in particular, I'm obviously
not offended by these many wonderful additions.
I think the danger arises when there's 2-3 more adoptions at the level
of StackOverflow or--just for kicks--say Google Docs or similar. The
big Kahuna? Per your PEG discussion, which flavor becomes the gorilla
for mobile developers (part. iOS nerds)? Because I REALLY think that's
going to come up a lot sooner than later.
I'd hate for all that wonderful diversity to turn into some markdown
version of _The Butter Battle Book_.
I wonder if it's time for Yalta. Or, a "Meeting of the Five Families,"
if you like. Do you suppose it's too fancy to propose something like a
standards committee that brings together all the MMDs and Pandocs and
PHP Markdowns and Discounts and what have you, to settle on:
* a core set of super-basic functionality that future-proofs users who
aren't "Inside Baseball"
* some forward-looking agreement on how all the wonderful diversity
can thrive without splitting the groups, breaking past (or future)
installs, confusing users, or forcing a One MD To Rule Them All
decision that chills innovation and discourages developers
As I am wont to disclose: I am NOT a real programmer. I mean it took
me six weeks to get pandoc running.
But I've been around just long enough to know that few really cool
bits of technology go mainstream without their architects settling on
standards that businesses and consumers can trust.
Put differently, trains need a standard for track. Once that's
settled, we can put whatever we want on our own train, but at least we
know the tracks are sound and won't need to be _skooched_ an inch
wider based on one engineer's preference.
Long. As usual. Sorry.
But given that you're obviously open to both feedback and re-thinking
right now, my suggestion for step zero would be to ensure that the
Markdown family sees eye to eye on basic interoperabilty. Personally,
I wouldn't count on Grubes to offer to chair this--I think it'll be up
to the devs and wizards.
Please let me know if I can help with _anything_. It means a lot to me
to have MD on my Mac and my Phone and God knows where else. I know I'm
not alone in that desire. And given how increasingly important $MD is
becoming to all of us, this might be a good time to see what can be
done to keep MD as easy to develop for as it is to use.
Now. How about also giving MMD a "`LINKS_EACH_PARAGRAPH`" option like
in `html2text.py.`[^jk] [^nr]
And thanks again.
mdm
[^jk]: Just kidding
[^nr]: Not really
On Nov 11, 7:13 am, "Fletcher T. Penney" <fletc...@fletcherpenney.net>
wrote:
dsanson
standardization of at least the core features of extended markdown.
There has been some discussion on the pandoc list of adopting
delimited YAML metadata blocks, for example: perhaps this is a good
moment to try to agree on a common metadata implementation for pandoc
and MMD? Also, the pandoc and citeproc-hs developers have recently
hammered out a syntax for citations that is significantly different
than syntax you have implemented in MMD. A common syntax for
citations---at least for the basic cases---would be a good thing.
-David
Fletcher Penney
doesn't necessarily make it better than something without an acronym.
:)
1) I think standardization on certain features amongst Markdown
derivatives would be nice. It seems to be a bit like herding cats
however as each of us has scratched our own itch. And Gruber clearly
seems to have no interest in adding any new features to Markdown or
blessing a "committee" to work on this.
2) What would be gained by using YAML instead of the current metadata
implementation? I'm not necessarily against it, but it would require
additional work, and I wonder what the payoff for that additional work
would be? The reason I chose the syntax I did is that it is
immediately intuitive to a person writing it, and to a person reading
it. There are a couple of dedicated fields with certain meanings
(e.g. title, author, date), but for the most part it's up to the
person writing the document to choose fields that are useful to them,
and then decide whether to use them in the final output (via LaTeX
commands, or something in XSLT). It's designed to support the core
fields almost everyone needs, while allowing whatever else is
important.
3) MultiMarkdown's "internal" citation syntax is as simple as
possible, or as complex as possible, depending on your perspective.
Basically, there is none. It simply takes whatever you enter as a
formatted string. Alternatively, it supports BibTeX if you're going
to output to a LaTeX document. I think the CiteProc project is great.
But I can do everything I need to do using BibTeX. I have no
personal interest in studying the way citations are managed, other
than "Can I output a paper that has citations in a reasonable style,
without redoing my entire workflow?" Since there are so many tools
that manage .bib files, and my finished documents with real citations
are almost always created through a LaTeX intermediate, there is no
reason for me to reinvent the wheel. MultiMarkdown was never intended
to be citation manager. If there are any changes to the way citations
are managed, it is likely to become simpler, not more complex. That
said, there's no reason one couldn't use other tools to manage the
citations within a MultiMarkdown document. And from what I saw in a
quick glance, the syntax for citations in citeproc-hs is [citekey].
In MMD it is [#citekey]. The difference is pretty trivial, but in my
mind clearly disambiguates an intended link from an intended citation.
The '#' may not be absolutely necessary, and that could be discussed.
Short version - I am not "against" citeproc, but certainly have no
plans to write a new implementation of it since I don't need it
personally. I would certainly consider making tweaks to make
MultiMarkdown "citeproc-friendly" as needed to allow compatibility
with other tools (just like I made it compatible with bibtex without
rewriting the vast craziness that is bibtex.)
F-
ovidius
On Nov 11, 4:13 pm, "Fletcher T. Penney" <fletc...@fletcherpenney.net>
wrote:
> interviewed about MMD on the Mac Power Users podcast (should come out
> this weekend), I had a little bit of free time, and I looked again at
> C implementations of Markdown. This has prompted me to think about
> where MMD is, and where it's going.
>
> # MultiMarkdown, the syntax #
>
> Otherwise, I think the syntax more or less has everything it needs to,
> keeping in mind that the goal is to remain simple and easy to read,
> *not* to implement every feature under the sun.
>
> Recent trends would seem to suggest many others agree - my twitter
> searches and google alerts are continuing to show more and more
> "chatter" about MMD, which is nice. While not necessarily my original
> goal, it is seeming to become the Markdown flavor of choice for
> writers. I can work with that.
1. MMD has unfortunately no good editing tools on Linux. I did manage
to use yasnippet and patch markdown-mode for Emacs, but this is far
from TextMate or Scrivener kind of work. For me it would be more
interesting to have some kind of converter into org-mode style. For
instance tables can be done inside Emacs with org-modes table mode
which is fantastic and it should be possible to have some kind of
conversion there. You should really consider the org-mode table syntax
[1], which seems much cleaner to parse and to understand than MMDs
IMHO.
2. I find that ditaa-like syntax [2] for diagrams would be a cool
addition to the language itself.
[1] http://orgmode.org/manual/Built_002din-table-editor.html#Built_002din-table-editor
[2] http://ditaa.sourceforge.net
>
> # MultiMarkdown, the program #
>
> Perl is easy. Perl is well-supported. Perl is not super-fast. Perl
> is not available on iPhone.
>
>
> https://github.com/fletcher/peg-multimarkdown
versions (C and Perl) coexist in future without leaving the Perl
version behind as legacy, but I guess that you alone cannot do this
work alone.
>
> And don't forget the new MMD Wiki:
>
> https://github.com/fletcher/MultiMarkdown/wiki
>
> Thanks!
>
> Fletcher
>
Ingolf
Fletcher Penney
discovered MultiMarkdown through your comments about it.
For a couple of years I have wanted just such a "committee." I even
composed a (rather wordy) email to send to the Markdown list to
propose just that, but deleted it before hitting send as I think
Gruber would be more supportive if it came from someone else (he seems
to really not like MMD for some reason. ;)
I think the core points are:
1) Markdown is great
2) Markdown is lacking a few features that many user want/need
3) Exactly which features are missing vary from person to person
4) Many users, left unchecked, would go crazy with feature bloat until
someone had to write a new Markdown to go back to something simple.
I have had many requests for new features for MMD, most of which I
have declined to add. I figure Markdown covers the features needed to
write 80% of documents out there (including web pages under the rubric
of documents). Hopefully, MMD adds features that cover another 10%.
A system that covered 100% is going to look more like Microsoft Word,
or LaTeX, than Markdown.
I do think, though, that there can be agreement to be had for a few
"core" additional features:
* footnotes
* citations (maybe)
* image attributes
* definition lists (who uses these things anyway? ;)
There may be agreement to be had on tables, but only under the idea
that they will be simple tables, and that sometimes you have to use
raw HTML (or something).
Some other features are probably not important enough to worry about,
or could be "optional" (glossaries being an example from MMD).
It would be nice to know that if one stuck to this "core" set of
extended features (yes, I see the irony there), that it wouldn't
matter what system one used to parse the document, and that your
documents would be intact when "compiled" by someone else.
I guess a bigger question, though, is "Under what circumstances has a
difference in the Markdown dialects truly affected someone?" I don't
want to standardize just for the sake of standardizing, if there's no
real benefit to be gained. Each of these authors has (hopefully) made
their decisions about syntax and features after weighing alternatives
and precedents. The core Markdown syntax will (basically) work with
any of the derivatives. If you need certain additional features you
choose the tool that offers them.
Which leads to my own plan for MultiMarkdown. I think most, if not
all, of the features it needs are in place. As mentioned, I think it
need to be faster, and I think the LaTeX workflow needs to be more
straightforward. Both of these have been accomplished with the
peg-multimarkdown program that is in development on github. I would
also like to get MMD supported on the iPhone/iPad. With a few more
steps, this should also be possible after some more work on
peg-multimarkdown. A second tier "wish list" would be a better way to
produce an ODF file than through Google Docs, and a better approach to
creating RTF files for those unfortunate souls who need to use them.
As for interoperability, I have been very careful while modifying
peg-markdown to become peg-multimarkdown to remain compatible with the
canonical Markdown test files (with one known exception) and to create
test files for MMD as I go in order to remain consistent. I would be
happy to cooperate with others to generate additional shared test
files for standardized behavior where appropriate.
(Much too long of a response --- I apologize, but I've been thinking
about these things quite a bit lately.)
I think what we need now is "fan support" for some shared standards.
John MacFarlane has been very helpful as I struggled to understand his
code while tinkering. I've had several emails from iOS developers
regarding requests for MMD support in their apps that currently
support Markdown. I'm sure that other developers of MD derivatives
would be willing to discuss these issues if it seemed that enough
people cared. Or maybe I should just send a bunch of them an email
and see what happens....
Thanks to anyone who actually read this far!
Fletcher
Sent from my iPad
Fletcher Penney
On Dec 7, 2010, at 3:54 PM, ovidius <ingolf....@gmail.com> wrote:
> I have two points here:
>
> 1. MMD has unfortunately no good editing tools on Linux. I did manage
> to use yasnippet and patch markdown-mode for Emacs, but this is far
> from TextMate or Scrivener kind of work. For me it would be more
> interesting to have some kind of converter into org-mode style. For
> instance tables can be done inside Emacs with org-modes table mode
> which is fantastic and it should be possible to have some kind of
> conversion there. You should really consider the org-mode table syntax
> [1], which seems much cleaner to parse and to understand than MMDs
> IMHO.
Every time I try to migrate over to Linux, I find two main things that
stop me. iTunes/iPhone support requires a Mac (Windows isn't an
option for me, and Linux support for the iPhone is really lacking to
put it kindly.) And I would miss TextMate. I've even tried to start
using command line editors to assist in that migration, but it's not
the same. I tinkered with working on a mmd variant of markdown-mode
but didn't make it very far.
As for the org-mode table syntax, I'm not sure how it's really
different than the current MMD syntax for the simple example on the
page you linked to. I have said all along however, that I would
gladly change the MMD table syntax if someone had a better solution
than what I'm currently doing, keeping in mind the goals of being easy
to read, easy to write, with an absolute minimum of markup "cruft".
It needs to look like a table for people, and not for computers. As I
dig through other pages on the orgmode site, the tables start to look
horrendous.
> 2. I find that ditaa-like syntax [2] for diagrams would be a cool
> addition to the language itself.
ditaa looks like an interesting program. Won't be part of MMD, but it
does look interesting. It looks like ditaa has an option to process
data embedded in HTML documents, so you could probably do something
like:
<pre class="textdiagram">
SOME DITAA CODE
</pre>
inside your MMD document and process it with ditaa after running it through MMD.
>> For those who are so inclined, check out the peg-multimarkdown fork:
>>
>> https://github.com/fletcher/peg-multimarkdown
>
> I will try it. IMHO going from Perl should only be done, if both
> versions (C and Perl) coexist in future without leaving the Perl
> version behind as legacy, but I guess that you alone cannot do this
> work alone.
The perl version will remain available. Not sure how much development
it will still need. Don't want to abandon it. Don't want to do twice
as much work. We'll see. But the syntax is the same, there's just a
change in what metadata fields are used.
Thanks for the feedback!
F-
Fletcher Penney
> Tables are adequate. For quick and simple tables it works.
>
> One of the 'bugs' of MMD, I consider to be a feature: <DIV> is a tag
> and starts the process of ignoring content, but <div> is not. (Or
> perhaps other ways around) This Bug/Feature allows me to either turn
> off processing or not. The cost of this is slight violation of the
> the xhmtl standard. Tags that are ignored are wrapped in <P> tags.
>
> Of course I would prefer MMD to produce valid XHTML. DIV, IMHO, is a
> generic container tag, and so should be passed through unchanged, but
> the contents still processed.
>
> Several MD variants have a flag you can put in the tag to do this.
> For DIV, HEAD, BODY, and HTML my preference would be that the default
> is to process the content, with a flag to NOT process it.
<div markdown=1> enables markdown within a div.
> The only other feature I really want is to be able to resolve links
> to an external file.
>
> Some links are used repeatedly on a web site. When you reorganize a
> web site, it takes a while to track these down, and correct them.
>
> My ideal behaviour would be as follows:
>
> * The present link creation syntax is supported.
> * If a link is not found in the document, the reference is matched
> against a simple database. This could be at once extreme, just a flat
> file with the structure reference | link path. Or it could be ndb,
> or somthing larger.
cat file.txt database.txt | MultiMarkdown.pl
Effectively does that already.
F-
Fletcher Penney
I have to admit that I think it fits well into the MMD concept, but I
don't relish trying to get it to work as seamlessly in a C app....
I'll keep working on this one. It will remain in the perl version of
MMD, but may require a different workflow in the C version.
F-
On Nov 12, 2010, at 3:56 AM, Alan Schmitt
<alan.s...@polytechnique.org> wrote:
dsanson
to be a "grand summit" to settle on a common standard, there still
might be ways to bring some of the existing extended syntaxes closer
together. (I don't think I'll try to extend the cat metaphor to cover
this.)
And I didn't mean to suggest that MMD should adopt YAML. YAML is quite
close to the current syntax for MMD metadata. I suppose they differ a
little bit on how lists are dealt with (e.g., multiple authors,
keywords) and expressive power (if we are talking about full-blown
YAML). And there is a question of how the metadata is delimited, if at
all. I do think that using something (or a subset of something) that
has an independent standard brings some benefits looking forward.
But YAML is a red herring. What I meant to point out was this: if
pandoc goes to YAML (or something like it), then the MMD syntax and
the pandoc syntax will be very close cousins; add to this the fact
that MMD is currently undergoing a rewrite; perhaps this is a good
opportunity for the two to converge. There is a great benefit for
users if the syntax is *exactly the same* rather than not quite. (But,
of course, one has to worry about breaking existing documents...)
As for citations, I did not mean to suggest that you should implement
citeproc! What an awful headache! All I meant to suggest was that it
would be nice if MMD and pandoc markdown shared a common *syntax* for
citations. How the citations are subsequently processed is a separate
issue. Perhaps this is just a question of whether or not to drop the
""#" (I think it might end up being more complicated then this, since
it will effect things like where the locator (e.g., p. 25) is put
too). And considerations like the one you give---that the "#" helps
clearly disambiguate that it is a citation---argue in favor of instead
having pandoc include a "#" or some such symbol. Again I didn't mean
to suggest that MMD should do it pandoc's way; just that if there is
the possibility of a common syntax (or, at least, a common syntax for
the simple cases), that would be a good thing. (But, again, there is
the worry about breaking existing documents...)
I'm sure similar comments apply to other areas where pandoc markdown
and MMD diverge: tables, math support, etc. These just seemed like two
cases where there might be a genuine opportunity for convergence.
And I should say: I really appreciate MMD. It's a great tool. The
project of moving it to C implementation, and the possibility of
having it in places I can't have perl is really exciting. (But also
worrying, since there are places, like some remote servers, where I
can have perl scripts but I cannot build or install C programs...)
David
Fletcher Penney
match others, provided there is no significant downside to changing
(I've changed the way footnotes worked in the past to match PHP MD
extra).
F-