| 1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
| 2 |
Hash: SHA1
|
| 3 |
|
| 4 |
On Tue, 24 Sep 2013 18:56:33 +0100
|
| 5 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
|
| 6 |
|
| 7 |
> hasufell <hasufell@g.o> wrote: |
| 8 |
> > I wonder if it would make any sense to take the effort to convert |
| 9 |
> > markdown docs to html format before installing them. |
| 10 |
> |
| 11 |
> Aren't there thirty seven different incompatible formats all called |
| 12 |
> "markdown", all of which require different tools to process correctly? |
| 13 |
|
| 14 |
Yeah, there are. But do we need to support them all? A lot of these
|
| 15 |
formats are used on websites alone; so, they are not relevant here. If
|
| 16 |
you boil it down to formats you store, use or process locally, it gets
|
| 17 |
shorter. Do we actually want to process all the alternatives correctly?
|
| 18 |
|
| 19 |
=======================================================================
|
| 20 |
TL;DR: Lack of standardization is a mess, let's work with what we have.
|
| 21 |
=======================================================================
|
| 22 |
|
| 23 |
When I hear Markdown I think about where it all started:
|
| 24 |
|
| 25 |
http://daringfireball.net/projects/markdown/
|
| 26 |
|
| 27 |
And I would propose we focus on that syntax to start with; if we want
|
| 28 |
to support a widely used alternative, we could implement support for
|
| 29 |
specifying which format is used and use a compatible converter.
|
| 30 |
|
| 31 |
We then come down to a popular alternative:
|
| 32 |
|
| 33 |
https://help.github.com/articles/github-flavored-markdown
|
| 34 |
|
| 35 |
Yes, I can see what you mean, it leads to certain inconsistencies; and
|
| 36 |
David Greenspan (not the actor; founder of EtherPad, now working
|
| 37 |
on Meteor) also noticed that about a year ago. He reached out to Jeff
|
| 38 |
Atwood which shared the same thought and reached out to a lot of people:
|
| 39 |
|
| 40 |
http://www.codinghorror.com/blog/2012/10/the-future-of-markdown.html
|
| 41 |
|
| 42 |
But apparently, this doesn't seem to have worked out so well; this is
|
| 43 |
because it is often used within the context of a website and the
|
| 44 |
Markdown contents aren't really exchanged among websites.
|
| 45 |
|
| 46 |
They are not really trying to standardize a protocol here, but rather
|
| 47 |
something people use when writing out a comment on some website; if
|
| 48 |
users then switch from Stack Overflow to Reddit they will barely tell
|
| 49 |
the differences in the particular behavior the syntax would produce.
|
| 50 |
|
| 51 |
GitHub is kind of an exception here, they allow you to place files in
|
| 52 |
your repository that you can read on their site or read on your device
|
| 53 |
as plain-text, using a Markdown viewer or a converter.
|
| 54 |
|
| 55 |
While a Markdown viewer has existed before that and you could just do
|
| 56 |
it; I don't recall it being common use in the back of the days, it's
|
| 57 |
only when you plan to exchange it across communities and / or people
|
| 58 |
that a standard becomes a necessity. GitHub has introduced exchanging.
|
| 59 |
|
| 60 |
But, are there other alternatives? Yes, there is the original; some
|
| 61 |
people might be writing their repository's README.md in that format,
|
| 62 |
unintended, then not noticing that GitHub reads it a bit differently.
|
| 63 |
|
| 64 |
It's going to be hard, but I think we might want to let the user decide
|
| 65 |
which particular implementation is in favor; or give the user some way
|
| 66 |
to switch back in forth, or let the user have the choice to use some
|
| 67 |
converter that attempts to implement the best of each format.
|
| 68 |
|
| 69 |
As long as websites use Markdown in their own way; we will be unable to
|
| 70 |
use a standard, let alone ensure that all the Markdown files we get to
|
| 71 |
read are in a particular standard for Markdown files in repositories.
|
| 72 |
|
| 73 |
Not until the big Markdown consumers step up and change the game.
|
| 74 |
|
| 75 |
Let's work with what we are given for now; but indeed, we should be
|
| 76 |
well aware that no standard is present and the future can change.
|
| 77 |
|
| 78 |
- --
|
| 79 |
With kind regards,
|
| 80 |
|
| 81 |
Tom Wijsman (TomWij)
|
| 82 |
Gentoo Developer
|
| 83 |
|
| 84 |
E-mail address : TomWij@g.o
|
| 85 |
GPG Public Key : 6D34E57D
|
| 86 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
|
| 87 |
-----BEGIN PGP SIGNATURE-----
|
| 88 |
Version: GnuPG v2.0.21 (GNU/Linux)
|
| 89 |
|
| 90 |
iQEcBAEBAgAGBQJSQgVRAAoJEJWyH81tNOV9lssIALs7e95SC7XnCZ2KpZlFSYvI
|
| 91 |
GqqIe8CrXrGn4f+xugmgSQgDc3QqNIxTj5lib/7K3pMOtZfqxwGsNe+nVWvlQ0sH
|
| 92 |
3jhUFIGhlcGdnBt+ibkkfrdyFmPa2lKXKzsK/XLzR2on0AezspeHtsWEfQzNLjBn
|
| 93 |
rgMOXDrIwHGgdOUKAerKW//6CJUhvvn6M9gxFImiLcQueKMNLxHBYm09dkbRU+XM
|
| 94 |
1/Yv5HhvqwbnVOtDIR9up736D3lv02ZmGg0kxvf7EjEJT+1TJDoS7kezamSXk+1o
|
| 95 |
xflwOLGcEURkRTQj39I9qZCO21yBnw6Ge/JDtNn6Tw94KysueTN/u7rtlPp8/rQ=
|
| 96 |
=MpAx
|
| 97 |
-----END PGP SIGNATURE----- |
Archives