Markdownfmt – Like gofmt, but for Markdown
github.com
github.com
$ pandoc -t markdown --atx-headers --no-wrap uglyfile.md
That has been my go to way to clean up some of my crufty markdown formatting. I have a variant `spretyymd` that pipes the output to aspell. Obviously this does not replace the file in situ or create diffs. In situ pipe processing is always risky sounding enough that I never thought about doing it.I wish someone would write an updated par with better documentation.
I've been dogfooding this for about a month for all my Markdown (mostly GitHub README.mds, comments to issues, etc.), and by now it's stable to cover my (admittedly, more basic) use cases of Markdown. I don't have explicit support for exotic Markdown features like tables at this time.
The Atom package has 100+ downloads by now, and I've only had 1 issue reported so far, so I'd be very curious to actually learn how many other people use it.
https://raw.githubusercontent.com/shurcooL/atom-markdown-for...
There are also some examples in tests:
https://github.com/shurcooL/markdownfmt/blob/d472cbc9d6118d6...
What do you mean by "unwrapping"? Can you give an example please. I don't think it should be doing any unwrapping; blockquotes should be preserved (and nicely formatted) [1].
> You went way past that line when you removed the empty line at the end of the file.
It makes sure the last line has an ending newline, nothing more, nothing less. Any extra newlines are not visible in the generated HTML.
[1] https://github.com/shurcooL/markdownfmt/blob/d472cbc9d6118d6...
Alice wants to conduct a survey of her customers. She wants to restrict
access to her customers (ie select subset of people) and she wants
customers to be able to answer openly and not worry about reprisals.
> Is there a magic token that Alice can distribute to her customers
> (Bob,Carol,etc) that demonstrates their membership in survey pool and
> protects the anonymity of their responses?
Transcript: dfc@ronin:~$ wc example.md
8 67 395 example.md
dfc@ronin:~$ .gopath/bin/markdownfmt example.md > gofmt.md
dfc@ronin:~$ wc gofmt.md
3 65 390 gofmt.md
dfc@ronin:~$ cat gofmt.md
Alice wants to conduct a survey of her customers. She wants to restrict a**SNIP**
> Is there a magic token that Alice can distribute to her customers (Bob,**SNIP**
dfc@ronin:~$
I truncated the lines in the cat gofmt.md because long preformatted colums kill HN readability. That file was 7 lines of pristine markdown with a trailing newline. markdownfmt turned it into three lines total. dfc@ronin:~$ pandoc -t markdown -o pandoc.md example.md
dfc@ronin:~$ wc pandoc.md
8 67 395 pandoc.md
dfc@ronin:~$
I am not sure what you mean by "It makes sure the last line has an ending newline, nothing more, nothing less. Any extra newlines are not visible in the generated HTML." I thought this was a markdown formatting tool?Here is a hypothetical--but common--workflow that this destroys: Author keeps multiple chapters of book in separate files for easy editing and revision control. When it is time to publish text the author executes:
$ cat 1.md 2.md 3.md 4.md |publishmd --some-options
You killed my chapter titles.It's related to the decision of whether to enable EXTENSION_HARD_LINE_BREAK, which I've currently left off. So in order to start a new paragraph, you need to leave a empty line in between.
It assumes you're using automatic word wrapping in your editor to wrap the paragraphs (this works well if you resize your editor width, or type extra text in the middle of it - the text within the paragraph is reflowed automatically and doesn't go offscreen).
I can understand that's a deal-breaker for you if you're not willing to use word wrap in your editor.
> So in order to start a new paragraph, you need to leave a empty line in between.
If you are aware of this why do you chomp the new line at the bottom of a file? I can no longer assume ` cat 1.md 2.md|sometool` will work. > $ cat 1.md 2.md 3.md 4.md |publishmd --some-options
>
> You killed my chapter titles.
I did not consider such a use case. Currently, markdownfmt works on an individual file/stdin and considers that to be the entire Markdown; it does not know that you're planning to concatenate more files.It would work fine if you passed `cat 1.md 2.md 3.md 4.md` as input, but removing excess newlines at the end of individual Markdown files will ruin the concatenated result.
It's similar to an issue that goimports also has [1].
I'll think about it, perhaps something can be done to solve this.
That explanation does not really make sense. I want markdownfmt to work on the file chapter1.md and the following day after editing chapter 2 I want to process chapter2.md. markdownfmt never needs to know and never will know that I use chapter1.md and chapter2.md together. When I am done I am going to feed chapter[1-X].md to another tool for publishing. But I cant because I used markdownfmt on a file by file basis and it damaged my files.
Every large book I have seen that uses markdown uses this chapter (or smaller) as file workflow. The biggest example that comes to mind is the progit book: https://github.com/progit/progit/tree/master/en
FWIW, the markdown files for all chapters in that book you've linked do not contain an extra newline at the end; there's only one (just like markdownfmt leaves it).
What about using something like cat, except one that inserts a newline between all the files it concatenates? That way the .md files can remain as they are.