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 05:45:09 -0600 Message-ID: <4f458997-0720-48c0-a075-0a1150d1985e@alphapapa.net> References: <87il36mevf.fsf@yahoo.com> <4a52da5c-2252-4956-b6b2-b452e5be8c9f@alphapapa.net> <875xz5nb2h.fsf@yahoo.com> <87o7cxlsgv.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="16489"; 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 12:45:39 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 1rWESo-00043w-Md for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Feb 2024 12:45:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rWESU-0001xn-At; Sat, 03 Feb 2024 06:45:18 -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 1rWESS-0001wx-Sd for emacs-devel@gnu.org; Sat, 03 Feb 2024 06:45:16 -0500 Original-Received: from dormouse.elm.relay.mailchannels.net ([23.83.212.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWESQ-0006lX-7w for emacs-devel@gnu.org; Sat, 03 Feb 2024 06:45:16 -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 8A29936401C; Sat, 3 Feb 2024 11:45:11 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a294.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 1AD843632BF; Sat, 3 Feb 2024 11:45:11 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1706960711; a=rsa-sha256; cv=none; b=luShDcMUTAPgUGX+9edeGVlWmizuqjYDe9h8Uce2/I7XymbO7QAJI0ksiZQ4zN8+1fTRgD t5Xmc/t1YNVjOZC8m1RMKJEJVSMUueCQumN1sYrcB8c3cOpfCXFAki4R1hUnc8y31TUvEv sH8h9e2xEhAthdrjWgH/S4+1YYTorRodNWBcA4zr0Ka50+2ANFuKBxxYGkO6DVqgucmFKZ CshF8tQbvklSz+2jSOF8xLMK7PYBjYga4mujUQkEi4AUqMc9Cve5xOYr9I+edWC9HhzH2q KB4xoK8h+U+HWYayB2/TJG6IHWQ3fFxKzo/DJ2WQp6dvUB3XLk7kvvwyNPdyIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1706960711; 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=VBHMEpdLsfmD6oql7vKcuxUGfeKZVG+fnt+sGMoHm2U=; b=oj8S+TE+br5qQsSv/6GTaM6dwi17eXlJEa3LHeK7LUWpJUF0+mI0/D6rfSpyDH3+qTQaE2 Y9YVh46r+8ksGrgdTwAenjSclb3vhpJnIKV09Q3UL4zUe9vsuI7kSUP4UUYBXG2npvjLix lKgb5d5PV1Rbl0ARujWMvD2NHHE7ft+JcHirebm2GNluvkM8ppikXk4tq+qXjjj3/jxDvh 49R1UEgD98r2KOLycwC74KTWkp2r7Ec8aDmmhxJo/ZxN2dgXbvENLbU282E8I/BDs7a/Ff XTW4pSU2355t4yTLRNaWqW+dyRgyeAbyU2ZVH1a3CX3fkkhvxS88R3xMtzqhOw== ARC-Authentication-Results: i=1; rspamd-55b4bfd7cb-4r2dq; 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-Suffer-Blushing: 7d4e3a09066f2961_1706960711361_2416334476 X-MC-Loop-Signature: 1706960711361:4195695011 X-MC-Ingress-Time: 1706960711361 Original-Received: from pdx1-sub0-mail-a294.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.109.231.231 (trex/6.9.2); Sat, 03 Feb 2024 11:45:11 +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-a294.dreamhost.com (Postfix) with ESMTPSA id 4TRrRV4RpvzBT; Sat, 3 Feb 2024 03:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1706960710; bh=VBHMEpdLsfmD6oql7vKcuxUGfeKZVG+fnt+sGMoHm2U=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=mOzcTXMlJSxc5Cm28uCD6V1DSVKmqH+jTvqCExLSrXJXQswE2JkJ0Y0xeVoWpwA7Y I+HSd1NPa/7F3CqMAY/2vtXjqUX91+kuLHOit7bkY2DTfDRYqnQNHmpuU31zwkMtQW Rm9X5Dsfg04j5saJcYMgg652198/CSuKRvSuhfP1nhu1PUmDuRRWm53r9eblEYQ0aW w4+dPzQ1QGbFmNz+oq26kHOryjEQ6Bh9c9egvVOogZWwDTVtqKvfhmgZZ9VTIHErfv lMPtQZnPDpnwNfVZp6d7sKXTKM7BNhdKJjNLhiL2Nr6B9vwxixi1Fygwl/G2p2cXAx /8piEocI3/hHw== Content-Language: en-US In-Reply-To: <87o7cxlsgv.fsf@yahoo.com> Received-SPF: neutral client-ip=23.83.212.50; envelope-from=adam@alphapapa.net; helo=dormouse.elm.relay.mailchannels.net X-Spam_score_int: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 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_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=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:315820 Archived-At: 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