all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: Po Lu <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 04:28:45 -0600	[thread overview]
Message-ID: <d6597aa8-85e6-4584-aaa7-1c0cbc1f5dd9@alphapapa.net> (raw)
In-Reply-To: <875xz5nb2h.fsf@yahoo.com>


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?



  parent reply	other threads:[~2024-02-03 10:28 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 [this message]
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=d6597aa8-85e6-4584-aaa7-1c0cbc1f5dd9@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.