unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Po Lu <luangruo@yahoo.com>
To: emacs-devel@gnu.org
Cc: Stefan Kangas <stefankangas@gmail.com>
Subject: Re: master 72b1379f079: Increase `emacs-lisp-docstring-fill-column` to 72
Date: Fri, 02 Feb 2024 22:02:51 +0800	[thread overview]
Message-ID: <87mssjm0ac.fsf@yahoo.com> (raw)
In-Reply-To: <20240202123506.0CEC7C0EFF5@vcs2.savannah.gnu.org> (Stefan Kangas's message of "Fri, 2 Feb 2024 07:35:05 -0500 (EST)")

Stefan Kangas <stefankangas@gmail.com> writes:

>     Increase `emacs-lisp-docstring-fill-column` to 72
>     
>     Monitors are wider now than when these defaults were first set, and it
>     is useful to take better advantage of that, to fit text on fewer lines.
>     Yet, it has repeatedly been shown that overly long lines reduce
>     readability:
>        "A reasonable guideline would be 55 to 75 characters per line."[1]
>     
>     We also don't want to disfavor narrow displays, like mobile phones; a
>     more promising direction here might be to automatically word wrap
>     docstrings and make their maximum width customizable.  That might
>     require a new docstring format, however.
>     
>     Bumping it by 7 characters, from 65 to 72, seems a reasonable compromise

Generally speaking, 65 columns is already excessive for mobile phone
displays, but only just, and it is usually possible to infer partially
obscured words while reading doc strings without scrolling lengthwise.
Filling doc strings to 72 columns removes that ability, forcing readers
to scroll the display back and forth to uncover obscured words, so it
can't be more of a compromise between narrow and wide displays than 65
columns is.

>     for now.  Consideration was given to increasing it to 70 or 75, but 72
>     happens to be a commonly recommended maximum line width elsewhere (see
>     Fortran 66, Python docstrings, commit message recommendations, etc.),
>     and we might as well do the same.
>     
>     This change was discussed in:
>     https://lists.gnu.org/r/emacs-devel/2022-07/msg00217.html

You'll excuse me if I've overlooked something, but judging by the
referenced thread alone, the change originally proposed was barely
discussed, and certainly did not generate enough debate to establish its
merits and deficiencies with any degree of certainty, let alone those of
imposing a new value on all Emacs users.  For making decisions about a
far-reaching departure from an ancient configuration, an inconclusive
thread over a year in the past is not a source of sufficient input, even
more so when the change which prompted that thread would only have
affected ourselves.



       reply	other threads:[~2024-02-02 14:02 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <170687730547.552.9673193819426474611@vcs2.savannah.gnu.org>
     [not found] ` <20240202123506.0CEC7C0EFF5@vcs2.savannah.gnu.org>
2024-02-02 14:02   ` Po Lu [this message]
2024-02-02 14:23     ` master 72b1379f079: Increase `emacs-lisp-docstring-fill-column` to 72 Stefan Kangas
2024-02-03  3:00       ` Po Lu
2024-02-03  3:09         ` Emanuel Berg
2024-02-03  7:43           ` Po Lu
2024-02-03  8:02             ` Emanuel Berg
2024-02-03  8:53             ` Eli Zaretskii
2024-02-03  9:45               ` Po Lu
2024-02-03 10:33                 ` Emanuel Berg
2024-02-03 11:18                 ` Eli Zaretskii
2024-02-03  9:48               ` Emanuel Berg
2024-02-03 11:23                 ` Eli Zaretskii
2024-02-03 11:57                   ` Emanuel Berg
2024-02-03 12:17                     ` Eli Zaretskii
2024-02-03 12:37                       ` Emanuel Berg
2024-02-03  8:04         ` Adam Porter
2024-02-03  8:25           ` Emanuel Berg
2024-02-03  9:36           ` Po Lu
2024-02-03 10:06             ` Emanuel Berg
2024-02-03 10:28             ` Adam Porter
2024-02-03 10:45               ` Emanuel Berg
2024-02-03 11:04               ` Po Lu
2024-02-03 11:17                 ` Emanuel Berg
2024-02-03 11:45                 ` Adam Porter
2024-02-03 12:34                   ` Emanuel Berg
2024-02-04  4:44                     ` Richard Stallman
2024-02-04  5:17                       ` Emanuel Berg
2024-02-07  3:12                         ` Richard Stallman
2024-02-03 11:13               ` Emanuel Berg
2024-02-03 13:43               ` Eric S Fraga
2024-02-03 21:56             ` Stefan Kangas
2024-02-03  8:31         ` Eli Zaretskii
2024-02-03 10:02           ` Po Lu
2024-02-03 10:16             ` Alfred M. Szmidt
2024-02-03 11:20             ` Eli Zaretskii
2024-02-03 12:12               ` Emanuel Berg
2024-02-03 21:47         ` Stefan Kangas
2024-02-03 23:14           ` Po Lu
2024-02-04  1:28             ` Emanuel Berg
2024-02-04  1:25           ` Emanuel Berg
2024-02-02 14:35     ` Emanuel Berg

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=87mssjm0ac.fsf@yahoo.com \
    --to=luangruo@yahoo.com \
    --cc=emacs-devel@gnu.org \
    --cc=stefankangas@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).