Re: master 72b1379f079: Increase `emacs-lisp-docstring-fill-column` to 72

[Adam Porter]

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