Hi! On Sat, 2026-02-07 at 17:23:11 -0800, Russ Allbery wrote: > This is mostly for Sean, but no reason not to send it to the list.
(Just to be clear, I think this is for you editors to decide, just "butting in" to give some hopefully helpful references and perspectives(?). :) > About a year ago, I personally stopped using two spaces after periods in > writing. I was taught that way and always used that formatting in email > and on Usenet, but that style of formatting is fairly obsolete these days > and for various personal reasons I wanted to adopt the new formatting. I've always found the two spaces after period quite odd, I guess because they are never used like that in Catalan and Spanish which I was taught with. It's fine when contributing to projects that use that convention which I try to follow, as part of making the changes blend in, but for projects I maintain, it means something I need to constantly keep consciously in mind as it does not really come out naturally (so I tend to convert those, either progressively or in bulk :). (Conversions in bulk are now more palatable to me given the support in git blame for «git config blame.ignoreRevsFile», where the convention is to use «.git-blame-ignore-revs».) > Policy currently largely, but not entirely, uses two spaces after periods. > When working on Policy, should I: > > 1. Use one space after a period in new text, let my editor reformat > rewrapped paragraphs to use one space after a period, and not worry > about the inconsistency. I think this is what's largely happening now. > > 2. Configure my editor to use two spaces after periods when editing Policy > and try to consistently maintain that style. > > 3. (A bigger change.) Start adopting XKCD 1285 formatting for Policy in > new text: each sentence on its own logical line (thus often longer than > 80 columns), with a newline at the end of each sentence. > At work, we use 3, and in general I prefer it, but it's a big change and > would mean lines in email messages for review would break the normal email > formatting conventions. It's quite nice in software forges and avoids the > problems with reflowing paragraphs causing spurious meaningless deltas in > Git, but as long as we're using email review, it might be a bridge too > far? I agree that diffs on prose can tend to be messy and annoying, and some times I use «git diff --word-diff» and others just «git diff»/«git show», maybe with some -b/-w sprinkled in. I find it important in the changes I create to have as a minimal diff as possible to make them trivial or easier to review and analyze (for example in a context where you only have a .patch generated from git), but many times this is impractical or not possible at all with prose with common formatting. I think the 80 columns limit still makes sense, as argued for example in <https://ux.stackexchange.com/questions/3618/ideal-column-width-for-paragraphs-online>. My experience with web tools for code review is that they are also not great when handling long lines, even with web tools that are otherwise superior (IMO) in many other axis (such as gerrit), but maybe I've failed to use some configuration to enable a better experience. What Simon describes in another mail seems pretty close to «Semantic Line Breaks» as specified in <https://github.com/sembr/specification>. And while I find it is not fully visually appealing and bit unnatural, I also find it functionally appealing and visually not completely unappealing, so I've been meaning to finish converting for example the dpkg documentation to some variant of that for a while <https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=next/man-sembr>. Thanks, Guillem
