Closed abathur closed 9 years ago
To play devil's advocate, we may also choose a middle path, where the rule of thumb is to wrap most markup to a fixed number of columns, but value preserving others (function synopses, code examples, URLs) un-broken in the source to reduce ambiguity.
Personally, I prefer not to wrap in the .rst, because I consider only the generated text output as being used productively in mud environments and I don't really want to limit to 78 chars in other media...
Ok; I agree. I've commented out the line-too-long rule in the linter I'm working on and converted two documents (efun/allocate.rst, efun/attach_erq_demon.rst). I can already tell that the two converted docs are easier to read/work with in an editor with intelligent wrapping.
The rest of these will need to happen as I am working through the docs for other purposes.
Because the generated plaintext output can be wrapped at any desired column, the question of whether our source should be wrapped at all (and if so, at what column?) is relevant. In theory the source is free from the constraints that require the plaintext to be wrapped, but if we want the source to be consumable as a "more-semantic plaintext documentation", wrapping at some point may still be prudent.