From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: master 72b1379f079: Increase `emacs-lisp-docstring-fill-column` to 72 Date: Sat, 3 Feb 2024 04:28:45 -0600 Message-ID: References: <87il36mevf.fsf@yahoo.com> <4a52da5c-2252-4956-b6b2-b452e5be8c9f@alphapapa.net> <875xz5nb2h.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13078"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org, stefankangas@gmail.com To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 03 11:29:54 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rWDHV-00038y-LD for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Feb 2024 11:29:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rWDGm-0004x7-Et; Sat, 03 Feb 2024 05:29:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWDGl-0004wy-2x for emacs-devel@gnu.org; Sat, 03 Feb 2024 05:29:07 -0500 Original-Received: from poodle.tulip.relay.mailchannels.net ([23.83.218.249]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWDGT-0002EX-F7 for emacs-devel@gnu.org; Sat, 03 Feb 2024 05:28:52 -0500 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3A33B902D27; Sat, 3 Feb 2024 10:28:47 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a239.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BA2AA902302; Sat, 3 Feb 2024 10:28:46 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1706956126; a=rsa-sha256; cv=none; b=NiYQ8kDMFCpmMUkBhrXOVoS1kBRIJSXOVtsm6BqXID2XDlsZ1xf+GQMkHVxvbDx9mosyTw +SkpBNYPEZ67GypLwNUjsQgMFmaZ2mDOPT34RSmj7l08gNxCMqwe0Y/kjjvl2tr/cEXVhl d5bNjNj9zAEKbXo+WQ2NWdEIgwDB8vzvXHmF0U6unhQyE5XXmgfEYlLec1l5dwvhp3E0Cg tDONUlkf2d1tpC2UiniEsYLS8oNWfiO+UhdL4uFhobg5i+liciviForK9pdeEN5fixtZcN pkUlaiFdxpi9bSRFdM6vSy66X32NZkv/tg8tG1RTdrIsnhv20Nmp4Iiok1XwVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1706956126; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xG85SmfvSW4iqaRig3bjNU9GwZ0TUWKgFbh7iu6wbT8=; b=XU685i9XTN8yTJ42BCAGgHut1ld3pH9QgCGIWH9cCyrlXQDRo9q58CqDsu2Hh5V5iij6dg pF2D4eTWKIR8lFsdqZqEc+0QAHnpgklBU/mbNjPS72eS6mibtLbMy4wbvFCHy5TuVDh20P lz0h1guGgPYdY4O5NkJlHEjw3DuMVKoWu8O7+oaseSGJ7IZR4k9Ga8xSoGHNNxY/D2hBcI oKvNq0ixVqO9PmvVtXgcpmBhjX76YlFQai+O2nD15SJf/PTXuvTWGl+h93sLZOHoxStwYR Aq0MmCwsN3ccplmzPuSAjIKOUkGPFx3SmHM53yfM0Dg9ubljpu3SXEde/f183Q== ARC-Authentication-Results: i=1; rspamd-6bdc45795d-f6rrg; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Lyrical-Bottle: 51fab3924306cef6_1706956126999_2773802729 X-MC-Loop-Signature: 1706956126999:121978984 X-MC-Ingress-Time: 1706956126999 Original-Received: from pdx1-sub0-mail-a239.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.124.22.107 (trex/6.9.2); Sat, 03 Feb 2024 10:28:46 +0000 Original-Received: from [10.60.0.178] (unknown [193.56.117.222]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a239.dreamhost.com (Postfix) with ESMTPSA id 4TRplL1zlzzF2; Sat, 3 Feb 2024 02:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1706956126; bh=xG85SmfvSW4iqaRig3bjNU9GwZ0TUWKgFbh7iu6wbT8=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=VCbk378+JptQwg18GP+/F6l2xVgxXg34q+usBIwvZ7zcK3bNNykdaE38ZVyFqWLrb tFmimwlgS6xudaq4Kf9Qs4w9DyWeJDOEpJDDh8Bsb6TpO+ofR9rLIXCzP6cTOXnLC7 klgWwU+e8jhIapbmqA0MrskYK/to2u57Xaer7xiRgdv+WSZV/4KRN/Pz4c9g+vEZ1G 0EQcFSRXwdkghqs2JGuVna4VJ1EhSluw9QXfl5W2zySfpF/K4LNbRUzZcUAdT7SmOE 9Den2VqOxRaee3ClKCn1cp0lcV5sJKamEtdxEdQ0s5LSuQJ6YyPp070/PfNsdm9Zcb xVnboooWxcLbQ== Content-Language: en-US In-Reply-To: <875xz5nb2h.fsf@yahoo.com> Received-SPF: neutral client-ip=23.83.218.249; envelope-from=adam@alphapapa.net; helo=poodle.tulip.relay.mailchannels.net X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315804 Archived-At: 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?