Re: [groff] man 7 groff; was nroff.1.man Make editorial fixes.

[John Gardner]

>
> *When writing *roff text, you'll need to break your lines anyway, if
> you're calling macros.*


I'm speaking much more broadly about plain-text and prose in general.
Specifically, mediums such as text-editors where soft-wrapping makes it
easier for authors to lose track of how much they're waffling on. Having
the length of each sentence visible in your editing window makes it easier
to spot uncomfortably long sentences, which generally indicates poor
wording or topic structure.

*Also, indenting code is purely cosmetic (unless you're using Python), so
it should be done using spaces*

Indentation conveys the structure of your program, and has a tremendous
impact on readability. *Alignment* is purely cosmetic, and should be done
with spaces, yes. I make sure to keep both tabs and spaces separate with at
least one visible (non-whitespace) character, so indentation stays semantic
in nature.

I also indent Python with tabs. Fight me.



> *Impressive.  Reminds me of the sample texts they used to have*
> *in typing courses way back when, which also managed to have*
> *exactly the same number of characters on every line.  How much**work did
> it take to finesse the text into being like this?*


Honestly? It's just second nature to me. Poke through the commit-logs of
literally any of my GitHub repositories
<https://github.com/Alhadis?tab=repositories>, and you'll notice every
paragraph is consistently  wrapped at exactly 72 columns, without
hyphenation or extra spaces.

I have this freakish intuition for knowing exactly where words will fall as
I'm typing them, which might be a byproduct of being a graphics designer
who "thinks" visually. I don't know. :-)

All I can say is I'm still unsure if I should be proud or embarrassed by
this ability...

On Wed, 3 Jul 2019 at 05:27, Tadziu Hoffmann <address@hidden>
wrote:

>
> > I advocate the "one sentence per line" rule [...]
>
> If you mean "one whole sentence per line", then I'll object.
> I think it's good to start each sentence on a new line, while
> still breaking the text at semantically convenient boundaries
> so that no source text line exceeds a certain limit
> (for example, 72 characters).
>
> When writing *roff text, you'll need to break your lines
> anyway, if you're calling macros.  And, for example,
>
>   implemented the even more ancient
>   .B runoff
>   of the
>   .I Multics
>   operating system
>
> is far easier to read than
>
>   implemented the even more ancient \fBrunoff\fP of
>   the \fIMultics\fP operating system
>
>
> Remember "The story of Mel"?  I'm not sure where this came from,
> but I think it has the appropriate cadence.  Also, many of these
> "common sense" guidelines for writing nroff text were even more
> useful in the days when "ed" was your text editor, since it was
> much easier to jump to a certain line than to change some words
> in the middle of a very long line of text.
>
>
>
>                            -=*=-
>
> > <https://raw.githubusercontent.com/Alhadis/Coding-Style/master/README.md
> >
>
> You forgot trailing space.  Anyone leaving trailing space
> in their code deserves to be publicly humiliated.
> (Unless achieving a particular result makes this necessary,
> of course.)
>
> [Also, indenting code is purely cosmetic (unless you're using
> Python), so it should be done using spaces.]
>
>
> > Text reflow? What the hell is that?
>
> Impressive.  Reminds me of the sample texts they used to have
> in typing courses way back when, which also managed to have
> exactly the same number of characters on every line.  How much
> work did it take to finesse the text into being like this?
>
>
>
>