all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Po Lu <luangruo@yahoo.com>
To: Adam Porter <adam@alphapapa.net>
Cc: emacs-devel@gnu.org,  stefankangas@gmail.com
Subject: Re: master 72b1379f079: Increase `emacs-lisp-docstring-fill-column` to 72
Date: Sat, 03 Feb 2024 19:04:00 +0800	[thread overview]
Message-ID: <87o7cxlsgv.fsf@yahoo.com> (raw)
In-Reply-To: <d6597aa8-85e6-4584-aaa7-1c0cbc1f5dd9@alphapapa.net> (Adam Porter's message of "Sat, 3 Feb 2024 04:28:45 -0600")

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.



  parent reply	other threads:[~2024-02-03 11: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
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 [this message]
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=87o7cxlsgv.fsf@yahoo.com \
    --to=luangruo@yahoo.com \
    --cc=adam@alphapapa.net \
    --cc=emacs-devel@gnu.org \
    --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.