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
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.
https://raw.githubusercontent.com/shurcooL/atom-markdown-for...
There are also some examples in tests:
https://github.com/shurcooL/markdownfmt/blob/d472cbc9d6118d6...