Discussion:
[Plone-docs] "One sentence per line"
Jean Jordaan
2012-04-08 15:08:57 UTC
Permalink
Hi there

Putting this out there for your thoughts:

By starting a new line at the end of each sentence, and splitting sentences
themselves at natural breaks between clauses, a text file becomes far
easier to edit and version control. Text editors are very good at
manipulating lines — so when each sentence is a contiguous block of lines,
your editor suddenly becomes a very powerful mechanism for quickly
rearranging clauses and ideas.

And your version-control system will love semantic linefeeds. Have you ever
changed a few words at the beginning of a paragraph, only to discover that
version control now thinks the whole text has changed?

from: http://rhodesmill.org/brandon/2012/one-sentence-per-line/

Documentation tends to be a rather personal thing, with different people used
to their own styles and the preferences of the editors that they use.

However it's also something we maintain in common, and that we version using
line-oriented tools.

As such, it would be good if we shared some understanding of how we want
things to work.

When I'm editing, I tend to re-flow very long lines to fit in 80 columns,
and I re-flow paragraphs when I've rewritten enough that most lines would
change anyway.

So I'd like to ask what your feelings would be about writing (or just reading)
short, ragged lines, and not reflowing paragraphs, for ease of editing &
versioning.
--
jean                                              . .. .... //\\\oo///\\
Mikko Ohtamaa
2012-04-10 15:03:41 UTC
Permalink
Post by Jean Jordaan
So I'd like to ask what your feelings would be about writing (or just reading)
short, ragged lines, and not reflowing paragraphs, for ease of editing &
versioning.
Personally I don't care

* Modern editors can wrap lines (take that, pico!)

* Also some people tend to justify text with somewhat sane line width
(60-160)

I am happy as long as hard tabs are avoided (which I often found myself
guilty).

BTW created / creating this tool to validate various files in git pre-commit
hook, including .rst - I hope to enforce
policy where one cannot submit bad entries using Git and also Travis CI
checks the files for bad Sphinx output:

https://github.com/miohtama/vvv

Cheers,
-Mikko


-----

Follow me in Twitter



Read my blog





--
View this message in context: http://plone.293351.n2.nabble.com/One-sentence-per-line-tp7447819p7453152.html
Sent from the Documentation Team mailing list archive at Nabble.com.
Jean Jordaan
2012-04-11 08:09:42 UTC
Permalink
On Tue, Apr 10, 2012 at 10:03 PM, Mikko Ohtamaa
Post by Mikko Ohtamaa
Post by Jean Jordaan
short, ragged lines, and not reflowing paragraphs, for ease of editing &
versioning.
Personally I don't care
Good :-)

While going through the dexterity manual, I formatted the last part
in that way. See the pull request:
https://github.com/giacomos/collective.dexteritymanual/pull/1
Post by Mikko Ohtamaa
* Modern editors can wrap lines (take that, pico!)
Yeah, but I think that wrapping paragraphs is often counterproductive for text
source files.
Post by Mikko Ohtamaa
* Also some people tend to justify text with somewhat sane line width
(60-160)
When the text source is meant to be read by many (e.g. README files), that make
sense. When it is mainly the source format for publication in other formats,
then not so much.
--
jean                                              . .. .... //\\\oo///\\
Dylan Jay
2012-04-11 22:01:04 UTC
Permalink
Post by Jean Jordaan
On Tue, Apr 10, 2012 at 10:03 PM, Mikko Ohtamaa
Post by Mikko Ohtamaa
Post by Jean Jordaan
short, ragged lines, and not reflowing paragraphs, for ease of editing &
versioning.
Personally I don't care
Good :-)
While going through the dexterity manual, I formatted the last part
https://github.com/giacomos/collective.dexteritymanual/pull/1
Post by Mikko Ohtamaa
* Modern editors can wrap lines (take that, pico!)
Yeah, but I think that wrapping paragraphs is often counterproductive for text
source files.
Post by Mikko Ohtamaa
* Also some people tend to justify text with somewhat sane line width
(60-160)
When the text source is meant to be read by many (e.g. README files), that make
sense. When it is mainly the source format for publication in other formats,
then not so much.
These manuals will eventually distributed with the plone source and
read from source.
Post by Jean Jordaan
--
jean . .. .... //\\\oo///\\
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-docs mailing list
https://lists.sourceforge.net/lists/listinfo/plone-docs
Loading...