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

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

[Po Lu]

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.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Generally speaking, 65 columns is already excessive for mobile phone
> displays,

Indeed.  I proposed a solution: patches welcome.

If we need to fix it in some other way for mobile displays in the
meanwhile, please work on that.  Info and many other things in Emacs
wrap to 72 columns, so we are already dealing with that problem.

It will take a very long time indeed before any significant proportion
of our docstrings have been reflowed to this new default, so we still
have plenty of time.

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

[Emanuel Berg]

Po Lu wrote:

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

IBM punched card - 80 chars
US teletypewriter - 72
new Emacs smartphone CPL standard - ?

This is what happens if one has stuff hardcoded BTW.
Maybe motivated to allow ascii art (boxes and arrows and
stuff) and allowing the programmer to fine-tune in an
easy way.

Still this situation then when new hardware is introduced.

https://en.wikipedia.org/wiki/Characters_per_line
https://en.wikipedia.org/wiki/Line_length

-- 
underground experts united
https://dataswamp.org/~incal

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Indeed.  I proposed a solution: patches welcome.
>
> If we need to fix it in some other way for mobile displays in the
> meanwhile, please work on that.  Info and many other things in Emacs
> wrap to 72 columns, so we are already dealing with that problem.
>
> It will take a very long time indeed before any significant proportion
> of our docstrings have been reflowed to this new default, so we still
> have plenty of time.

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.

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

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

[Emanuel Berg]

Po Lu wrote:

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

Well, are the info pages displayable on smartphones?

If it works there, it should work for docstrings as well.

If two numbers work, the higher the better since such a line
can hold more data.

It can make sense to have all hard-coded CPL stuff the
same value. Easier to remember if nothing else.

-- 
underground experts united
https://dataswamp.org/~incal

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

[Po Lu]

Emanuel Berg <incal@dataswamp.org> writes:

> Well, are the info pages displayable on smartphones?

They are not.  But that was not my point.

> If it works there, it should work for docstrings as well.
>
> If two numbers work, the higher the better since such a line
> can hold more data.

What problems came of the old value of 64, so urgent that it was
necessary to install this change (which, let us not forget, affects
_all_ Emacs users) on such short notice?  I'm less opposed to this
change in itself than to how it was fast-tracked into Emacs by one
individual citing an inconclusive discussion a year removed.

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

[Emanuel Berg]

Po Lu wrote:

> What problems came of the old value of 64 [...]

I can only see one reason to decrease: to make it fit.

And one reason to increase: to allow for more chars.

So shouldn't it just be as high as possible, while
still fitting?

-- 
underground experts united
https://dataswamp.org/~incal

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

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

[Emanuel Berg]

Adam Porter wrote:

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

100% - one wants as many chars as possible, it fills up quickly.

Yes, that's right - to the trained eye, that line has
1 sentence, 12 words, and exactly 64 characters.

As you can imagine you would like much more than
that, optimally.

Especially if the function has long ARGUMENT names that
requires bulky terminology, references etc, to be explained.

And it doesn't matter how little is a little, why not just
give us as many chars as possibly that are still
safe-displayable without the need for side-scroll?

Masterminds of technology, science and engineering should
think what to say, now how to say it so it will fit in a small
place that many consider ungenerous, claustrophobic even?

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Sat, 03 Feb 2024 15:43:46 +0800
> 
> What problems came of the old value of 64, so urgent that it was
> necessary to install this change (which, let us not forget, affects
> _all_ Emacs users) on such short notice?

And what problems do you envision from the new value?

> I'm less opposed to this change in itself than to how it was
> fast-tracked into Emacs by one individual citing an inconclusive
> discussion a year removed.

I'm surprised that you are opposed to something that has close to no
effect on the doc strings.  It sounds like another bikeshedding to me.

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

[Po Lu]

Adam Porter <adam@alphapapa.net> writes:

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

The distinction to bear in mind is that users of registers are
outnumbered overwhelmingly by readers of doc strings, and thus even a
minor change to the format of doc strings will impact more people than a
change to the mechanics of saving and restoring registers, even though
doc strings are not as frequently the subject of active interaction.

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

The rhetorical implications of these two questions take an absolute
stance on the relation between change and debate, which is not helpful.
What I would have liked to see was neither a categorical dismissal of
the change, nor an exhaustive and involved plebiscite of the entire
user-base, but an opportunity for interested individuals to have brought
their viewpoints to the table before the change was installed.

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

Whether that is true or not, raising the limit by 8 characters creates
very little improvement in all of these respects.  Even the worst of
modern displays can guarantee Emacs 80 columns of space, so it is not a
convincing compromise, and cannot be described except as an arbitrary
choice.

However, the more important issue is that such a discussion as we are
having now should have predated the installation of the change, and my
attempt to initiate one after the change should not have been answered
by an ultimatum eliminating all but the least feasible option.

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

I was not attempting to interpret your words, but to explain what
factors, IMHO, gave rise to the generally hostile nature of the
responses it received, so please don't regard it as any reflection on
yourself.

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

The proper time for asking that question was when both formats were
still being designed.  Consistency is a far cry from an end in itself,
and the only ends here are aesthetic in nature.

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Date: Sat, 03 Feb 2024 15:43:46 +0800
>> 
>> What problems came of the old value of 64, so urgent that it was
>> necessary to install this change (which, let us not forget, affects
>> _all_ Emacs users) on such short notice?
>
> And what problems do you envision from the new value?

Doc strings in old code will be a different width from those in new
code, and more difficult to read on mobile phone displays, which were
bizarrely stated as part of the change's rationale in the commit
messages.

> I'm surprised that you are opposed to something that has close to no
> effect on the doc strings.  It sounds like another bikeshedding to me.

Its effect will become visible over time, we simply don't know what they
will be, and could all have benefited from some advance notice.

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

[Emanuel Berg]

Eli Zaretskii wrote:

>> I'm less opposed to this change in itself than to how it
>> was fast-tracked into Emacs by one individual citing an
>> inconclusive discussion a year removed.
>
> I'm surprised that you are opposed to something that has
> close to no effect on the doc strings.

It will have an 8 char or +12.5% effect on the doc strings.

This is 64 chars:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

This is 72 chars:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

> It sounds like another bikeshedding to me.

On the contrary - as shown, the increase from 64 or 72 can be
counted, computed, and illustrated.

72 is also a better number because it is the original
US teletypewriter standard, from where it went to become
a general computer standard (including our own info pages, as
was mentioned by other posters).

-- 
underground experts united
https://dataswamp.org/~incal

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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

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

I only do so when the filling commands fail to produce properly
formatted messages, such as when a table or long symbols are present
which the filling commands wrap pedantically for being only 1 or two
characters past the fill column.

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

Before responding, I tried to measure the impact of this change by
running:

  (mapatoms (lambda (atom)
	    (when (functionp atom)
	      (and (documentation atom)
		   (insert (documentation atom) "\n")))))

in a buffer, with the fill column set to 72, and typing C-x h M-q.  Upon
restoring the fill column to 64 and enabling the fill column indicator,
the number of lines and words beyond it increased visibly.  So this is
not so insignificant a detail.

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

[Emanuel Berg]

Po Lu wrote:

> Whether that is true or not, raising the limit by 8
> characters creates very little improvement

The improvement is 8 chars or 12.5%.

Compare a 64 char line to a 72 ditto by looking at these bars:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

> in all of these respects. Even the worst of modern displays
> can guarantee Emacs 80 columns of space, so it is not
> a convincing compromise, and cannot be described except as
> an arbitrary choice.

80 is the IBM punchcard standard, 72 is the US teletypewriter.

See the Wikipedia page on CPL [1] - it mentions 72 four times,
including

  Many plain text documents still conform to 72 CPL out of
  tradition (e.g., RFC 678).

The RFC document refered to mentions 72 three times, including

  A [...] page is [...] 72 characters wide

> Consistency is a far cry from an end in itself, and the only
> ends here are aesthetic in nature.

Incorrect, 72 is obeying tradition and in practice 8 more
chars helps.

Indeed, the word "practice" is exactly 8 chars. If one
imagines a doc string that is 10 lines, that is 80 more chars.

Whatever one does hands on, any sudden improvement of over
a tenth is guaranteed to be experienced immediately.

[1] https://en.wikipedia.org/wiki/Characters_per_line

[2] https://www.rfc-editor.org/rfc/rfc678

-- 
underground experts united
https://dataswamp.org/~incal

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

[Alfred M. Szmidt]

   Before responding, I tried to measure the impact of this change by
   running:

     (mapatoms (lambda (atom)
	       (when (functionp atom)
		 (and (documentation atom)
		      (insert (documentation atom) "\n")))))

   in a buffer, with the fill column set to 72, and typing C-x h M-q.  Upon
   restoring the fill column to 64 and enabling the fill column indicator,
   the number of lines and words beyond it increased visibly.  So this is
   not so insignificant a detail.

That is I think not a good comparison, nobody is suggesting to re-fill
all docstrings to 72 (or even 64!) columns.  Many docstrings are
manually filled, so refilling everything would be far worse than
raising the fill-column to 72 (though, I think maybe setting it to
just fill-column might make more sense ... but whatever).

So this seems to be making a mountain out of a molehill, the current
fill-column makes docstrings in general "cramped" to read -- even on
80x25 terminals.  And seeing that there is no consitency in how
docstrings are filled, the minor raise in the limit is negligible --
you would only re-fill after modifying a docstring in some manner, and
in that case the text will get jumbled anyway.

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

[Adam Porter]

On 2/3/24 03:36, Po Lu wrote:

> users of registers are outnumbered overwhelmingly by readers of doc
> strings

That's probably true, but it would be hard to quantify that.  As well, 
as I said, it's apples-and-oranges between a workflow involving key 
sequences and a display format.

As I said, the only potential problem I can imagine is a user who's 
heavily customized the window configuration or display-buffer-alist so 
that docstring-showing windows are precisely 64 characters wide. 
Inconveniencing them would be regrettable to some extent, but enough to 
not change the value?
>> 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.
> 
> The rhetorical implications of these two questions take an absolute 
> stance on the relation between change and debate, which is not
> helpful. 

I'm not sure what you mean.  I don't think my stance is absolute; 
rather, it's more that we should use good judgment in each case rather 
than a set of rules.

> What I would have liked to see was neither a categorical dismissal of
> the change, nor an exhaustive and involved plebiscite of the entire
> user-base, but an opportunity for interested individuals to have
> brought their viewpoints to the table before the change was
> installed.
Ok, but where should the line be drawn between allowing maintainers to 
make such minor changes according to their judgment, and requiring some 
arbitrary amount of discussion beforehand?  What if the maintainers' 
judgment is that sufficient discussion has happened?

> Whether that is true or not, raising the limit by 8 characters
> creates very little improvement in all of these respects.  

I, for one, would welcome 8 more characters in my docstrings.  But, as I 
said, I don't care that much, either.

> Even the worst of modern displays can guarantee Emacs 80 columns of
> space, so it is not a convincing compromise, and cannot be described
> except as an arbitrary choice.
Any decision is ultimately arbitrary, no?  Even the decision to not 
change it.

>> 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.
> 
> The proper time for asking that question was when both formats were 
> still being designed.  Consistency is a far cry from an end in
> itself

Weren't those formats designed decades ago?  Don't our screens have 
orders of magnitude more pixels now?  Should we be limited by those old 
limitations forever?

> the only ends here are aesthetic in nature.
I don't understand why you repeat that claim, because it's been 
mentioned several times that increasing the limit provides a tangible 
benefit.  You seem to think that that benefit is negligible, but that 
doesn't mean that it is non-existent, nor that the benefit seems 
negligible to others.

I understand your procedural objection.  Besides that, is there a 
technical problem you object to?

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

[Emanuel Berg]

Po Lu wrote:

> Doc strings in old code will be a different width from those
> in new code, and more difficult to read on mobile phone
> displays [...]

Ah, so that is the reason 64 was suggested instead of 72.

Let me guess, an 80 char terminal emulator app and the text
gets too small? But not in horizontal mode, right? (Actually
I don't like that mode back and forth, annoying.)

Okay, let me return to this issue when I have seen the
smartphone situation first hand.

-- 
underground experts united
https://dataswamp.org/~incal

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

[Emanuel Berg]

Adam Porter wrote:

>> Whether that is true or not, raising the limit by 8
>> characters creates very little improvement in all of
>> these respects.
>
> I, for one, would welcome 8 more characters in my
> docstrings. But, as I said, I don't care that much, either.

8 new chars is an improvement beyond doubt but it is
a smartphone world now. And in the future - even more so.

He is right we should look our best in that world as well.

I actually have a smartphone right here! So I'll see if I can
install Emacs and see how it looks first hand.

-- 
underground experts united
https://dataswamp.org/~incal

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

[Po Lu]

Adam Porter <adam@alphapapa.net> writes:

> That's probably true, but it would be hard to quantify that.  As well,
> as I said, it's apples-and-oranges between a workflow involving key
> sequences and a display format.
>
> As I said, the only potential problem I can imagine is a user who's
> heavily customized the window configuration or display-buffer-alist so
> that docstring-showing windows are precisely 64 characters
> wide. Inconveniencing them would be regrettable to some extent, but
> enough to not change the value?

Where the twenty year old default value of a variable is concerned, the
decision is not whether to retain the old value but whether to change
it.

> I'm not sure what you mean.  I don't think my stance is absolute;
> rather, it's more that we should use good judgment in each case rather
> than a set of rules.

I meant that you implied the existence of a binary choice between a vote
among all users and relying on the completely arbitrary judgment of one
person.

> Ok, but where should the line be drawn between allowing maintainers to
> make such minor changes according to their judgment, and requiring
> some arbitrary amount of discussion beforehand?  What if the
> maintainers' judgment is that sufficient discussion has happened?

I don't think it's wise to enter into a dispute on the extent to which
relativism applies to Emacs, since most of my premises are accepted by
everyone involved, specifically in relation to this change.  Namely that
there should be a rationale and opportunity for comment, references to
both of which figured in the commit description.  My problem is that any
reasonable person will agree that the discussion linked was not in the
least productive and is too distant in time to be a suitable factor for
decision-making.

> Any decision is ultimately arbitrary, no?  Even the decision to not
> change it.

It's not a decision to do nothing.

> Weren't those formats designed decades ago?  Don't our screens have
> orders of magnitude more pixels now?  Should we be limited by those
> old limitations forever?

That's not our choice, but Texinfo's.

> I don't understand why you repeat that claim, because it's been
> mentioned several times that increasing the limit provides a tangible
> benefit.  You seem to think that that benefit is negligible, but that
> doesn't mean that it is non-existent, nor that the benefit seems
> negligible to others.

Likewise.

> I understand your procedural objection.  Besides that, is there a
> technical problem you object to?

As I said, I object to both, but to the former much more than to the
latter.
cwThanks.

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

[Emanuel Berg]

Adam Porter wrote:

> I understand your procedural objection. Besides that, is
> there a technical problem you object to?

He says it doesn't look good on smartphones.

I failed to verify this, there was no GNU Emacs app on
iPhone/iOS and I cannot use the terminal emulator apps to ssh
to the server and try Emacs from there, since for that to work
authentication assets would have to be brought over from the
desktop to the smartphone. And, because I don't really care
for Emacs or Unix shells on smartphones, I won't bother - not
now anyway.

I used to have a lovely Sony phone on Android, however it was
recently disintegrated. I assume that is where the GNU Emacs
app is to be found?

If so, maybe someone can upload screenshots how it looks, both
in vertical and horizontal mode?

-- 
underground experts united
https://dataswamp.org/~incal

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

[Emanuel Berg]

Po Lu wrote:

> Where the twenty year old default value of a variable is
> concerned, the decision is not whether to retain the old
> value but whether to change it.

If you can show us the GNU Emacs smartphone app with
screenshots, that would be an interesting demonstration.

How many chars can be displayed, and what happens if a line is
that many chars long plus one?

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 03 Feb 2024 17:45:22 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Date: Sat, 03 Feb 2024 15:43:46 +0800
> >> 
> >> What problems came of the old value of 64, so urgent that it was
> >> necessary to install this change (which, let us not forget, affects
> >> _all_ Emacs users) on such short notice?
> >
> > And what problems do you envision from the new value?
> 
> Doc strings in old code will be a different width from those in new
> code

No, they won't be, judging by what we already have.  See my other
message which explains why.

> > I'm surprised that you are opposed to something that has close to no
> > effect on the doc strings.  It sounds like another bikeshedding to me.
> 
> Its effect will become visible over time

Over a very very very long time.  Nothing to care about, really.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 03 Feb 2024 18:02:52 +0800
> 
> > 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.
> 
> Before responding, I tried to measure the impact of this change by
> running:
> 
>   (mapatoms (lambda (atom)
> 	    (when (functionp atom)
> 	      (and (documentation atom)
> 		   (insert (documentation atom) "\n")))))
> 
> in a buffer, with the fill column set to 72, and typing C-x h M-q.  Upon
> restoring the fill column to 64 and enabling the fill column indicator,
> the number of lines and words beyond it increased visibly.  So this is
> not so insignificant a detail.

This is a misunderstanding: I think it's insignificant because we
mostly don't pay attention to this setting anyway.

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sat, 03 Feb 2024 10:48:15 +0100
> 
> Eli Zaretskii wrote:
> 
> >> I'm less opposed to this change in itself than to how it
> >> was fast-tracked into Emacs by one individual citing an
> >> inconclusive discussion a year removed.
> >
> > I'm surprised that you are opposed to something that has
> > close to no effect on the doc strings.
> 
> It will have an 8 char or +12.5% effect on the doc strings.

No, it won't, because we fill our doc strings mostly "by hand",
disregarding the fill-column setting.

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

[Adam Porter]

On 2/3/24 05:04, Po Lu wrote:

> Where the twenty year old default value of a variable is concerned, the
> decision is not whether to retain the old value but whether to change
> it.

Aren't those two ways of describing the same decision?

>> I'm not sure what you mean.  I don't think my stance is absolute;
>> rather, it's more that we should use good judgment in each case rather
>> than a set of rules.
> 
> I meant that you implied the existence of a binary choice between a vote
> among all users and relying on the completely arbitrary judgment of one
> person.

Apparently I misunderstood you to be requesting a democratic poll about 
changing the option's value.  We seem to agree that that would be 
impractical and inappropriate.

But I don't understand what you mean about the judgment of one person 
being insufficient.  I have in the past objected to such a decision 
(although one that is much more impactful)[0], but aren't the 
maintainers appointed to make such decisions?

>> Ok, but where should the line be drawn between allowing maintainers to
>> make such minor changes according to their judgment, and requiring
>> some arbitrary amount of discussion beforehand?  What if the
>> maintainers' judgment is that sufficient discussion has happened?
> 
> I don't think it's wise to enter into a dispute on the extent to which
> relativism applies to Emacs, since most of my premises are accepted by
> everyone involved, specifically in relation to this change.  Namely that
> there should be a rationale and opportunity for comment, references to
> both of which figured in the commit description.  My problem is that any
> reasonable person will agree that the discussion linked was not in the
> least productive and is too distant in time to be a suitable factor for
> decision-making.

I don't understand: You say you want decisions like this to be made more 
publicly and after suitable discussion, but you decline to provide any 
criteria by which one could judge whether such a decision warranted such 
a process, or whether such a process was suitable; and you also say that 
a maintainer shouldn't make such a judgment call.  That doesn't seem to 
leave room for decisions to be made by any means.

>> Weren't those formats designed decades ago?  Don't our screens have
>> orders of magnitude more pixels now?  Should we be limited by those
>> old limitations forever?
> 
> That's not our choice, but Texinfo's.

I'm confused: Do you mean that Emacs's docstrings should be limited by 
Texinfo's limitations?  Earlier you said, "As for Info and 'many other 
things', they are not doc strings, and should not be factors in 
decisions regarding them."

>> I understand your procedural objection.  Besides that, is there a
>> technical problem you object to?
> 
> As I said, I object to both, but to the former much more than to the
> latter.

So I guess that would call for a thread about Emacs's development 
procedures, but as I noted, you seem to be declining to discuss that 
matter specifically.  So what is left?

0: https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01406.html

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

[Emanuel Berg]

Eli Zaretskii wrote:

>>>> I'm less opposed to this change in itself than to how it
>>>> was fast-tracked into Emacs by one individual citing an
>>>> inconclusive discussion a year removed.
>>>
>>> I'm surprised that you are opposed to something that has
>>> close to no effect on the doc strings.
>> 
>> It will have an 8 char or +12.5% effect on the doc strings.
>
> No, it won't, because we fill our doc strings mostly "by
> hand", disregarding the fill-column setting.

Okay, a misunderstanding here.

Because it doesn't matter how the editing happens or how the
doc string is produced, a maximum of 72 allowed chars compares
to 64 as described.

It is the extra capacity that is counted, not the actual
length of all docstrings currently found all over the
documented Elisp world.

If one writes a 10 char docstring, one still has the extra
space at 72 compared to 64, one just didn't use it.
That's another thing.

But of course the extra space will be used!

-- 
underground experts united
https://dataswamp.org/~incal

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

[Emanuel Berg]

Eli Zaretskii wrote:

> This is a misunderstanding: I think it's insignificant
> because we mostly don't pay attention to this
> setting anyway.

Ah, you mean you are not gonna have the byte-compiler,
checkdoc and all complain?

This is not a proposed new convention but _only_ used when
someone tries to fill the docstring?

Then I agree it makes no sense to discuss since the Emacs
programmer will just type the docstring so that it doesn't
overflow. A lot of lines will be closer to 80 chars than 72,
as long as they don't overflow it is all good.

Well, I'm happy you guys weren't as crazy as I thought.
Super short docstrings at 64 chars, the extra space isn't
needed! It all made no sense.

Po Lu, why did you feel so strongly about this? Even if you
had the described problem on smartphones, and even if people
had used it, so many docstrings would still have overflown
majorly. Absolutely nothing to be bothered about since it
won't solve the situation anyway. If it was or wasn't
discussed in a way that upset you, it was probably not meant
as disrespect, rather it was considered a non-issue.

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sat, 03 Feb 2024 12:57:20 +0100
> 
> Eli Zaretskii wrote:
> 
> >> It will have an 8 char or +12.5% effect on the doc strings.
> >
> > No, it won't, because we fill our doc strings mostly "by
> > hand", disregarding the fill-column setting.
> 
> Okay, a misunderstanding here.
> 
> Because it doesn't matter how the editing happens or how the
> doc string is produced, a maximum of 72 allowed chars compares
> to 64 as described.

That's a misunderstanding again: this is not about disallowing
doc-string lines longer than 72 character.  The variable only affects
what happens when you M-q in the doc string or turn on auto-fill-mode.

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

[Emanuel Berg]

Adam Porter wrote:

> Apparently I misunderstood you to be requesting a democratic
> poll about changing the option's value.

Po Lu, congratulations, you fooled us this time!

Your passion about it made us think it was a convention or
standard that was supposed to be enforced, a new rule that
said ridiculously short docstrings lines at 64 chars have
been increased to allow 72 after people freaking out about it,
and now you wanted it back to 64 out of concern
for smartphones :O

And it wouldn't have helped the smartphone situation anyway
since for that, it would have had to be a convention or rule
that was enforced and people were to stick to!

Many of my docstrings are closer to 80 cols than 72 BTW, just
think what insane work, trimming all that down to 64 in
solidarity with Android GNU Emacs users.

Well, I'm happy you all hadn't lost it, let's leave it at
that :)

-- 
underground experts united
https://dataswamp.org/~incal

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

[Emanuel Berg]

Eli Zaretskii wrote:

> That's a misunderstanding again: this is not about
> disallowing doc-string lines longer than 72 character.
> The variable only affects what happens when you M-q in the
> doc string or turn on auto-fill-mode.

Yeah, I understand now. 100% misunderstanding, ha.

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eric S Fraga]

On Saturday,  3 Feb 2024 at 04:28, Adam Porter wrote:
> As I said, the only potential problem I can imagine is a user who's
> heavily customized the window configuration or display-buffer-alist so
> that docstring-showing windows are precisely 64 characters
> wide. Inconveniencing them would be regrettable to some extent, but
> enough to not change the value?

I'm one of those that has a /heavily customised window configuration/
and I cannot see that this change will bother me much.  If I find that
my help window popups (left side on my wide landscape monitor) are now
too narrow, I'll simply adjust one number in my display-buffer-alist.

Much ado about nothing really (in my opinion, of course) and definitely
not akin to the register change late last year.

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> 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),

It seems like you think I didn't mean what I said, or in other words
that I wasn't replying honestly.  That's not the case.

IIUC, the problem you seem to be concerned about is that Emacs doesn't
wrap docstrings on narrow displays (mobile phones).  We seem to agree
that this is not currently supported.

The claim that wrapping docstrings to 65 characters in any way solves
that problem is just wrong.  It is the same as ignoring the problem,
perhaps simply because it happened to work on the one screen we bothered
to test with (using some font and font size, letter spacing, etc.).

I described the only solution I see, which is a new docstring format.
Designing a new docstring format is obviously not a small task, but it
would have many important benefits.

It's quite a big blemish that for an editor that prides itself on its
high quality documentation to have such a limited markup for docstrings.
Our docstring format does have one important upside: its relative
simplicity.  But IME it's only simple for the simple cases.  It was
probably not too bad at some point in the past, but the world in 2024
looks very different, and users expect more.

The markup itself is more like a bunch of cobbled together hacks that
have amassed organically over years than a proper markup language.
It doesn't only lack important features like word wrapping, but also:

  - bold, italic, etc.
  - lists (numbers and bullets)
  - variable width text
  - tables
  - semantically marking arguments
  - proper hyperlinks
  - an actually good way to markup keybindings and commands
  - maybe dividers and subheaders
  - etc.

This project has the potential to make our help system better for users
and developers, more consistent, easier to navigate, and so on and so
forth.  I think it's a very worthy endeavor.

> In truth, there has been _nothing_ to suggest that the
> width of doc strings has inconvenienced our users in any manner,

Increasing the fill column for docstrings will not inconvenience users
more than the current default does.

Also, knowing Emacs, the overwhelming majority of docstrings are likely
to continue being wrapped to 65 characters for years to come.  I expect
that we will have a new docstring format long before they are all
rewrapped.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Whether that is true or not, raising the limit by 8 characters creates
> very little improvement in all of these respects.  Even the worst of
> modern displays can guarantee Emacs 80 columns of space, so it is not a
> convincing compromise, and cannot be described except as an arbitrary
> choice.

While 80 or even 90 characters is perfectly fine for code, where most
lines are much shorter in practice, the story is not necessarily the
same for prose.

All studies that I've seen have been unequivocal about the fact that too
long lines hurt readability.  You will find this noted also in pretty
much any typographical handbook you care to pick up.  The advice given
in the study I quoted was to use 55-75 characters, and 72 characters is
within that range.

BTW, your math is off: the old default was 65, and not 64.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> 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),
>
> It seems like you think I didn't mean what I said, or in other words
> that I wasn't replying honestly.

Not at all!  I only wanted to express that your reply carried the tone
of an ultimatum, and that this uncompromising defense of change is, in
my observations, one of the principal factors behind the bitterness
perceptible in every discussion touching the subject, e.g. those on
defaults, of which December's conversations on registers is a prime
example.

I don't have the time to respond to the remainder of your email at the
moment.

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

[Emanuel Berg]

Stefan Kangas wrote:

> The claim that wrapping docstrings to 65 characters in any
> way solves that problem is just wrong. It is the same as
> ignoring the problem, perhaps simply because it happened to
> work on the one screen we bothered to test with (using some
> font and font size, letter spacing, etc.).

Yes, as long as it is hard coded it's gonna be a problem
across platforms.

But there are also advantages with having it hard-coded, e.g.
ascii art, tables and other formatting - that is all put there
manually, so offers complete freedom and precision, to those
that are into such perfectionist/pleasant documentation work.

A solution could be, keep it hard-coded by default.

But introduce an option, "help-wrap-lines" or something like
that, when set, lines will be wrapped automatically when
displayed by the help. In the docstring to the option, it will
say explicitely, "note that this method may not display
docstrings exactly as intended by the docstring writer."

So whenever 80 chars won't work, for example on smartphones if
that is the case right now, one would use that option
if desired.

In general, I like the help system in its simplicity.
Re-writing it from scratch I disencourage from but sure, add
new features to make it more interactive, intuitive
and powerful.

Here are my configuration and extensions, 90 LoC:

  https://dataswamp.org/~incal/emacs-init/help-incal.el

-- 
underground experts united
https://dataswamp.org/~incal

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

[Emanuel Berg]

Po Lu wrote:

>> It seems like you think I didn't mean what I said, or in
>> other words that I wasn't replying honestly.
>
> Not at all! I only wanted to express that your reply carried
> the tone of an ultimatum, and that this uncompromising
> defense of change is, in my observations, one of the
> principal factors behind the bitterness perceptible in every
> discussion touching the subject, e.g. those on defaults, of
> which December's conversations on registers is
> a prime example.

Perception is reality, if you experienced it that way from your
perspective, that is how you experienced it.

And, while opposing perspectives won't merge, both are
as real even (especially) if radically different.

But instead tell us then, how do you think it should be solved
so it'll work on both desktops and smartphones?

-- 
underground experts united
https://dataswamp.org/~incal

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Many of my docstrings are closer to 80 cols than 72 BTW, just
  > think what insane work, trimming all that down to 64 in
  > solidarity with Android GNU Emacs users.

Text on a terminal viewed in Emacs needs to fit in 79 columns.
But sometimes text gets indented a few columns.  So it is not good
to use all 79 colunms,  Please make doc strings fit easily.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Emanuel Berg]

Richard Stallman wrote:

> But sometimes text gets indented a few columns. So it is not
> good to use all 79 colunms, Please make doc strings
> fit easily.

If you would say a definite number, maybe it is something for
checkdoc to detect and complain about?

I use it to check my docstrings whenever I remember to do so,
it is a really helpful and cute little tool for that purpose.

(checkdoc-current-buffer t)

-- 
underground experts united
https://dataswamp.org/~incal

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If you would say a definite number, maybe it is something for
  > checkdoc to detect and complain about?

I don't recall all the factors that went into this decisio, over a
decade ago.  I just wanted to remind people of one specific factor
that we shouldn't overlook.

Another pertinent factor is hat making the maximum width customizable
would not solve anything.  The reason to have this convention is to
get all Emacs Lisp developers to format their doc strings in such a
way that users in general won't have problems reading those doc
strings.

Sure, different users may have different needs in regard to maximum
width of doc strings they read -- for rational reasons.  But we can
only have one convention about this, and letting different developers
follow different conventions is not a solution.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)