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?
next prev 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.