If you have better information, I’m all ears.
In my experience (using lots of different Markdown-related tools), .md is the most common extension, with .markdown a distant second. The rest of them (.mdown, .mkdn or whatever) I’ve never encountered in the wild (but some of the editors I’ve used support them).
Why you want to reuse the Markdown extension? CommonMark is not Markdown.
After reading previous comments, I propose .mark and text/mark for the MIME-type.
They are both unused.
.mark sounds good, though .md is used more often. If commonmark is highly compatible with gruber’s markdown, just stick to .md, if not then try .mark.
Btw, just notice that R statistic program name their fancy styled markdown document as .rmd to indicate that it is a markdown formatted document that has inline executable R snippets.
Whatever extension you choose like .md or .mark, I recommend adding a ‘Recommendation’ for filenames like .R.mark for R or .py.mark for python. So at least the file can be read even if there is no python or R hooks in the CommomMark reader.
For any file claiming to contain Markdown, the .markdown extension is the most readable and logical. The .md extension is most widely used. All other variations (.mdown, .mkdn, .markdn) are neither readable nor widely used, and as there are 49 ways of arranging the letters of the word into an extension, we should ignore those all.
However, to call CommonMark Markdown would be similar to calling LESS and SASS CSS. Yes, the original subset is still supported in the new language, but the new language is so much more.
Unless CommonMark’s development halts today, it will be a very different beast next year. It will support syntaxes and extensions that have never been valid Markdown. Just like how CommonMark has a name that’s distinct from Markdown, I support giving it an extension and MIME-type distinct from Markdown, and I like Sanpi’s proposed .mark extension.
Why you want to reuse the Markdown extension? CommonMark is not Markdown.
CommonMark is Markdown (I mean, every cmark implementation works as a markdown parser, but the opposite isn’t true).
Thus, .md extension works just fine here. It is popular, and cmark just doesn’t differ enough to warrant a change.
Not exactly: Is CommonMark really Markdown "compatible"? - #2 by codinghorror
A new extension doesn’t means you can’t parse .md file as CommonMark, but prevent parsing CommonMark file with a markdown parser.
@Tewha7 GitHub displays both .md and .markdown (for at least 8 months), see https://github.com/idleberg/Creative-Commons-4.0-Markdown
I don’t think there’s any need to support anything but .md and .markdown. Short version, long version — anything in between doesn’t make much sense.
I realize .md is the most common extension, however it’s also used by GCC machine description files and Modula. Vim, for example, only recognizes .md as Markdown in README.md by default [source]. The second most widely supported extension is .markdown. Other extensions are not supported everywhere (for example, the second shortest .mkd is not supported by Bitbucket) and I find them unreadable anyway.
Conclusion: In my opinion, .markdown should be the officially endorsed standard, but tools should probably also support at least .md where feasible.
Syntax highlighters need either an extension or a hashbang, else they have to resort to more complicated heuristics.
A common convention on Unix/Linux systems is for executable files to have a hashbang and no extension, and for libraries to have an extension (.pl, .py, .rb, etc.) and no hashbang.
You can’t really have extensionless files on Windows; for example, README will be recognized as a README file.
Therefore, Markdown certainly does need an extension. Now, I’m not saying there should be just “one true extension”, but a standard would be certainly nice—one that makes sense, i.e. not something like .text.
This is a good reason to recommend .markdown as the primary/official file extension instead of .md.
But first there should probably be some kind of standard extension.
We were having discussion elsewhere where one person wanted to change file ending from .md to .markdown, but it was stopped with two reasons:
Is it possible to also use the ‘naturalization argument’? That the majority of markdown files out there in the wild is already named “.md”, so any files we read should be in “.md” (if we are strictly compatible with majority of markdown formatted files).
If we are not strictly compatible with majority of markdown files, then we should use .cm or .mark, or .mk. Thought an argument can be made that .md is a generic file extension for lightly marked up text, and thus is not markdown specific.
That might be the way to go and we could also to look at the extension apps save Markdown files in. I personally use iA Writer for Mac which saves files with the .md extension by default (but recognises other extensions like .markdown). We could do a comparison of apps which read and write Markdown files and list what file extensions are used.
It’s a poor metric because without the file being present, Github tells you to create a file called README.md. Not a file called README.md or README.markdown.
If you don’t see that as a black mark big enough to make the metric useless, I’m honestly not sure how why we’d continue this conversation.
It doesn’t really matter why ~90% of Markdown files use .md. It only matters that they do.
The purpose of Common Markdown is not not invent new stuff. It’s to standardize what’s already there.
In standardizing a thing explicitly not to be standardized, a new thing is created. That appears to be recognized, as a new name was picked. A new extension should be picked as well.
It does not prevent Markdown from being processed by Commonmark. It prevents Commonmark from being processed by Markdown.
The half in/half our nature of this project will be its undoing. I’ve already lost most of my interest in the project as a whole over this thread.
No, we were forced to pick a new name, due to the original author of Markdown’s opposition to this effort.
I don’t think that follows. We’re trying to standardize Markdown, not create a new fork with its own file extensions.
That is against the goals of Common Markdown. The whole idea is to be as backwards compatible as possible.
That’s fine. We don’t all have to agree.
Perhaps it’s useful to point out here that we don’t have an .html5
extension – even though HTML 5 is definitely different from HTML 4.
“.md is better because it is shorter I don’t want file names to take my whole screen in width”
We’re not living in the world of 8.3 file names for a long time now. The same argument could be applied to .torrent as well, which is only one character shorter than .markdown. Short extensions can be nice but .md is already ambiguous even without Markdown.
For what it’s worth, it seems as of revision 6292, Vim recognizes all .md files as Markdown (not counting possible ftdetect magic). The first release that includes this is Vim 7.4.480 (based on revision 6293).
$ hg blame runtime/filetype.vim | grep -i markdown
[...]
6292: au BufNewFile,BufRead *.markdown,*.mdown,*.mkd,*.mkdn,*.mdwn,*.md setf markdown
6292: " Modula 2 (.md removed in favor of Markdown)
[...]
$ hg tags | grep -E '\s6(29[2-9]|[3-9][0-9][0-9]):' | tail -n -1
v7-4-480 6293:e3149e2b4152