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 can not say enough about pandoc. Atleast once I week I say "Why didn't you just pandoc -x -y -z it?" I am looking forward to the orgmode reader developments.
This is actually the first summer pandoc got a gsoc student to! (via haskell.org umbrella org). A lot of great work will be landing this summer, including some neat support for URL encoded inline images (and a bunch of other great things)
I figured now was as good time as any to post this, after seeing jsfmt posted today.
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.
btw, I don't know if it's just me, but I found it confusing that you had main.go in the subfolders... I generally assume main.go is only used in packages are that are executables, so it looked like the project had 3 executables in it.
I can live with condensing numbered lists and removing the blank lines between items. Unwrapping plain text paragraphs is worse but not the end of the world. We start to toe the line with unwrapping my blockquotes. You went way past that line when you removed the empty line at the end of the file.
> Unwrapping plain text paragraphs is worse but not the end of the world. We start to toe the line with unwrapping my blockquotes.
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.
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.
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.
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.
Is saying this is similar to an issue in goimport a sly way of saying markdownfmt "works on a file-by-file basis like gofmt; and as such it does not and cannot know that file a.go and b.go belong to the same package. Put another way, this is a user error for the tool as is."?
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
I understand the problem, I'm thinking how to best solve it.
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.
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.
I wish someone would write an updated par with better documentation.