all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: stefankangas@gmail.com, emacs-devel@gnu.org
Subject: Re: master 72b1379f079: Increase `emacs-lisp-docstring-fill-column` to 72
Date: Sat, 03 Feb 2024 10:31:48 +0200	[thread overview]
Message-ID: <86frya3q4r.fsf@gnu.org> (raw)
In-Reply-To: <87il36mevf.fsf@yahoo.com> (message from Po Lu on Sat, 03 Feb 2024 11:00:04 +0800)

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 03 Feb 2024 11:00:04 +0800
> 
> My point was that the circumstances of this change demonstrate that
> December's debacle was completely lost on the parties involved.  It
> should have taught us (again) that users do not take kindly to being
> surprised by arbitrary choices a handful of individuals decide to
> implement that they were not consulted about, yet within two months of
> the event a much more wide-reaching change is installed in an identical
> manner, of which criticism is met by an ultimatum to either complete a
> task that stands little chance of success (designing and securing the
> universal adoption of a new doc string format), or accept the change as
> a fact of life.
> 
> I trust many people will agree with me that increasing this variable
> from 64 to 72 is an exclusively aesthetic change, driven by personal
> opinions formed towards the appearance of doc strings, and perhaps in
> the belief that a lack of change is likely to be perceived as
> stagnation.  In truth, there has been _nothing_ to suggest that the
> width of doc strings has inconvenienced our users in any manner, and
> likewise none to suggest widening it will bring about an indispensable
> improvement.
> 
> As December's affair should have demonstrated, such arbitrary actions,
> when normalized, give rise to a neurotic user-base constantly at each
> other's throats, apprehensive of the next update to Emacs which might
> break their configurations or interfere with their habits in new and
> unseen ways, and belligerent in their defense of their existing
> practices and preferences.  I mean this literally--Eshel Yaron's blog
> post being one example, numerous others exist also, such as the sea of
> acrimony formed on Reddit in response to a package developer's request
> not to use Emacs 30, which was not so much related to Emacs as it was a
> collection of accusations of rudeness, immaturity, and bitter general
> faultfinding, or the hostility that radiates from every discussion on
> the subject of better or worse defaults, compilation failures induced by
> updating to new versions of Emacs, and the like.  Worse yet, I can sense
> myself warming to them by the hour.

Please excuse me for being blunt, but this is a tempest in a teapot.
To see why, please collect the statistics of the line length of our
doc strings: you will see that we already have a lot of them that
exceed even the new value of 72.  The reason is simple: it is very
rare to fill doc strings using fill commands.  I, for one, almost
never do that, instead "filling" them by hand to make each line, and
the doc string in general, read reasonably.

So I think this setting should affect almost no one, and making a
showcase out of this change just misses the entire point of the
"December's debacle".  We have more important stuff to discuss than
this insignificant detail.



  parent reply	other threads:[~2024-02-03  8:31 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   ` master 72b1379f079: Increase `emacs-lisp-docstring-fill-column` to 72 Po Lu
2024-02-02 14:23     ` 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 [this message]
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

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

  git send-email \
    --in-reply-to=86frya3q4r.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    --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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.