toc VS specification

I agree that on modern hardware recompiling is pretty fast. I have a 445 page book (https://gitlab.com/jim.hefferon/toc) with more than a graphic per page and lots of code inclusion, cross references, etc. The command "time pdflatex book" gives this on my 2016 laptop under Ubuntu.

real 0m18.159s

Yes. I've written a couple of books and having it all in one place just gets to be too much stuff. Here is a sketch of my current layout (exact is at https://gitlab.com/jim.hefferon/toc ), which I've had good luck with.

The fonts are here.

If you publish to HTML from a format that uses double line breaks as paragraph breaks, such as Markdown, you should strongly consider putting line breaks after each sentence. This leads to more useful diffs. If you do that consistently, full stops at line end are sentence ends; full stops within a line are not.

Markdown's treatment of white space is a feature, not a bug. It supports semantic line breaks.

Prefer breaking lines between sentences first, then at clause boundaries, then, if necessary, at smaller units. This makes it more likely that you get meaningful, readable diffs when using a version control system. See https://sembr.org/ for examples, guidelines, and further explanations.

If you prefer this in the form of a Creative Commons-licensed spec for some reason, https://github.com/sembr/specification

> How is that difficult? Most text editors support word wrapping and syntax highlighting.

To add to this, I personally prefer using semantic linefeeds — adding a newline after each sentence or clause (as in e.g. [0] [1]). I find this works exceptionally well with LaTeX, since I get the benefit of the newlines as I write and edit, while the typeset version is formatted nicely into paragraphs for me.

(Not that this is unique to LaTeX, of course; Markdown would be no different. The technique works well with all such tools.)

[0] https://vanemden.wordpress.com/2009/01/01/ventilated-prose/

[1] https://sembr.org/

SemBr author here. I chose SHOULD NOT for this rule for a couple reasons: First, as an affordance for text with ambiguous or unknown meaning. Second, as a hedge against introducing new meaning unintentionally.

Adding a semantic line break inherently changes the relationship between words, and we can't always be sure about the intended meaning of text. If this were MUST NOT, then any modification would risk violating the spec.

Then again, this may be my own, idiosyncratic reading of RFC 2119. If you'd like to discuss this further, feel free to open an issue on the GitHub repo here: https://github.com/sembr/specification/issues