all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: luangruo@yahoo.com
Cc: emacs-devel@gnu.org, stefankangas@gmail.com
Subject: Re: master 72b1379f079: Increase `emacs-lisp-docstring-fill-column` to 72
Date: Sat, 3 Feb 2024 02:04:29 -0600	[thread overview]
Message-ID: <4a52da5c-2252-4956-b6b2-b452e5be8c9f@alphapapa.net> (raw)
In-Reply-To: <87il36mevf.fsf@yahoo.com>

Hello Po,

> 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 don't think these two things are comparable.  The change to register 
commands affected users' workflows, i.e. the keypresses they make by 
habit after many years of usage.  Having a change like that appear 
suddenly is kind of like finding a new pothole in a road one travels 
every day (although one that shouldn't require a paving machine to fix, 
being Emacs).

Having symbol docstrings be 8 characters wider will probably not affect 
many users negatively.  I'm sure there are a few who have their windows 
precisely limited to the necessary width; if possible, it would be good 
to make it easy for them to keep such configuration with pleasant 
results.  But should that keep the docstrings at 64 characters wide forever?

And are we to vote on such changes across the whole user population? 
This seems like the kind of change that the maintainers are to make 
using their best judgment.

> 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.

I don't agree.  While I don't feel strongly either way, as one who 
frequently writes new docstrings, the arbitrary limit is felt.  One 
often must resort to awkward wording or abbreviated variable names to 
fit within it.  And if one doesn't do so, one can't get a clean linting 
pass.  Meanwhile, any window in my Emacs sessions that displays a help 
buffer has many columns of blank space to the right of the docstrings. 
And the existing limit is far from being too wide to be read comfortably.

> 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.

I'm not sure how to interpret your characterization of the thread I 
posted on Reddit.  For the record, I was not being critical of the Emacs 
development process; I was suggesting to users that, unless they want to 
actively participate in the Emacs development process (i.e. by 
faithfully reporting bugs that are discovered in unreleased versions), 
they should use released versions of Emacs; and that they should 
definitely use only released versions of Emacs when reporting bugs to 
package developers, because otherwise I can't try to reproduce the 
reported problems without running such an unreleased version myself.

Then, as usual, the discussion went its own way, largely misinterpreting 
my initial comment, but that's Reddit (and life).

> As for Info and "many other things", they are not doc strings, and
> should not be factors in decisions regarding them.

They seem somewhat comparable in that they are displayed similarly in 
Emacs buffers and are wrapped to a certain width.  One could ask why 
their appearances shouldn't be more consistent.

--Adam



  parent reply	other threads:[~2024-02-03  8:04 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 [this message]
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

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

  git send-email \
    --in-reply-to=4a52da5c-2252-4956-b6b2-b452e5be8c9f@alphapapa.net \
    --to=adam@alphapapa.net \
    --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.