linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	corbet@lwn.net, jake@lwn.net, djwong@kernel.org,
	dchinner@redhat.com, ritesh.list@gmail.com, rgoldwyn@suse.com,
	jack@suse.cz, linux-doc@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-block@vger.kernel.org, p.raghav@samsung.com,
	da.gomez@samsung.com, rohan.puri@samsung.com
Subject: Re: [PATCH] Documentation: add initial iomap kdoc
Date: Thu, 18 May 2023 23:15:24 -0400	[thread overview]
Message-ID: <ZGbpzBIZHBqgmTbz@mit.edu> (raw)
In-Reply-To: <ZGY7aumgDgU0jIK0@infradead.org>

On Thu, May 18, 2023 at 07:51:22AM -0700, Christoph Hellwig wrote:
> On Thu, May 18, 2023 at 07:50:03AM -0700, Luis Chamberlain wrote:
> > On Thu, May 18, 2023 at 07:48:54AM -0700, Christoph Hellwig wrote:
> > > > +**iomap** allows filesystems to query storage media for data using *byte ranges*. Since block
> > > > +mapping are provided for a *byte ranges* for cache data in memory, in the page cache, naturally
> > > 
> > > Without fixing your line length I can't even read this mess..
> > 
> > I thought we are at 100?
> 
> Ony for individual lines and when it improves readability (whatever
> that means).  But multiple to long lines, especially full of text
> are completely unreadable in a terminal.

For C code, if you have really deeply nested code, sometimes it's
better to have some lines which are longer than to have gratuitous
line break just to keep everything under 72-76 characters.

But if you are writing a block of text, and you are expecting people
to read it in a terminal window, I think it is adviseable to wrap at
72 characters.  In fact, some will advise wrapping earlier than that,
to better aid comprehension.  For example:

   "Optimal line length or column width for body text is 40–70
   characters.  When people read, their eyes jump across a line of
   text, pausing momentarily to take in groups of three or four
   words. Studies have shown that readers can make only three or four
   of these jumps (or saccades) per line before reading becomes
   tiring.

   Too long lines with too many words also make it harder for the eyes
   to find the correct spot when they sweep back to the left to pick
   up the next line of text. To maintain readability, it is imperative
   to use moderate line lengths within the range of 40–70 characters.

   Do not set normally sized body text in a single column across a 8.5
   by 11 inch page. If you do that, the result will greatly exceed 70
   characters, reading efficiency will be significantly reduced, and
   your readers’ attention will be easily lost.

   Two column layouts are the best solution for achieving optimal body
   text column widths on American letter size paper. If that is not
   practical and using only one column is necessary, then be sure to
   use large side margins in order to bring the line length as close
   as possible to 70 characters or less."

   -- https://winterpm.com/

Cheers,

						- Ted

  parent reply	other threads:[~2023-05-19  3:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-18 14:40 [PATCH] Documentation: add initial iomap kdoc Luis Chamberlain
2023-05-18 14:48 ` Christoph Hellwig
2023-05-18 14:50   ` Luis Chamberlain
2023-05-18 14:51     ` Christoph Hellwig
2023-05-18 14:54       ` Jonathan Corbet
2023-05-19  3:15       ` Theodore Ts'o [this message]
2023-05-19  9:28 ` Bagas Sanjaya
2023-05-19 15:13   ` Randy Dunlap
2023-05-19 23:25     ` Dave Chinner
2023-05-21 16:43       ` Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZGbpzBIZHBqgmTbz@mit.edu \
    --to=tytso@mit.edu \
    --cc=corbet@lwn.net \
    --cc=da.gomez@samsung.com \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=jake@lwn.net \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=p.raghav@samsung.com \
    --cc=rgoldwyn@suse.com \
    --cc=ritesh.list@gmail.com \
    --cc=rohan.puri@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).