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 02:04:29 -0600 Message-ID: <4a52da5c-2252-4956-b6b2-b452e5be8c9f@alphapapa.net> References: <87il36mevf.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="2662"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org, stefankangas@gmail.com To: luangruo@yahoo.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 03 09:05:22 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 1rWB1d-0000TD-K1 for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Feb 2024 09:05:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rWB0v-0006aI-69; Sat, 03 Feb 2024 03:04:37 -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 1rWB0t-0006aA-7Y for emacs-devel@gnu.org; Sat, 03 Feb 2024 03:04:35 -0500 Original-Received: from slateblue.cherry.relay.mailchannels.net ([23.83.223.168]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWB0r-0008RR-HT for emacs-devel@gnu.org; Sat, 03 Feb 2024 03:04:35 -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 E1AD8142D47; Sat, 3 Feb 2024 08:04:30 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a314.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 86E33142E24; Sat, 3 Feb 2024 08:04:30 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1706947470; a=rsa-sha256; cv=none; b=aDsXy43ujx11CvGaW3/9VDqz6ucLg21yDPondfGlk4s1MzQwkZvlSW2GGDS4rx+2ZOMfhA mnh7cH13OgBJ8okcUbywC+q6HYr5d794x+W/mxNM5MYwsumqTuwx1LvTwc4IPhT1yFDhYN l/dAaYTG2D0jEcnT9mlcj2O9tu008NUl1qlKFfqxRx8XpVAGeGLFMA8xKjX9vW+9BRb87G DnFDotHB6boxeF6sBPQwv4OKNRxMRb7+0gj7ab5MxEriorPs44yA5O+JRrvKqdqVjcdaqw nuVo1Me5eYfGDyTGpMu8KTLWnZILVqG3GXJEYqFMRkevnYn2ERL6xhLaHJjMtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1706947470; 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=9zRNU0fEquLBKaDt8X6VAu4dO9liuGDl7P/ar9gXUUE=; b=kBjx+rtfiey+iG8UAt8mDVIu4/2Xgf8ZCKO1wSQuDSo7PYbYEj/oLmSe16HKrat56jzDHd hFS76vs9hCzodxzKnPHmkRb8yzd7XlNcn4+RIyNKSxZTWyzyvnHtEpW2xhWcPBbHzhyO3p 26F6FQhOQ+lViokjS65x7fzGIzfOGaQsVpbi6W2OBueAvg22q1V9AX7fRjdx84e94YsMAV N4uBPzLsG54DVUF88uy34tsYRWQZ5gvR5RTJXRCrOyEFrixjBpo8WTJMT5BilnUsrIr8LR 4Tb+TxE5RiWpaNc03SPcQ3AADjwcbQwi72fFyjU3XJ24PGM8+iCW6ZpujrnnwQ== ARC-Authentication-Results: i=1; rspamd-55b4bfd7cb-wltlk; 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-Wiry-Lettuce: 0961c45b50de2726_1706947470794_3401907720 X-MC-Loop-Signature: 1706947470794:1508964042 X-MC-Ingress-Time: 1706947470793 Original-Received: from pdx1-sub0-mail-a314.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.100.20.149 (trex/6.9.2); Sat, 03 Feb 2024 08:04:30 +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-a314.dreamhost.com (Postfix) with ESMTPSA id 4TRlXt0WHYz62; Sat, 3 Feb 2024 00:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1706947470; bh=9zRNU0fEquLBKaDt8X6VAu4dO9liuGDl7P/ar9gXUUE=; h=Date:To:Cc:Subject:From:Content-Type:Content-Transfer-Encoding; b=d68ah2umJdZO+vQ9XwbHu4LA4jj6EcOb7SEcE5UDsDFIi/vy6X6nVYxTdd1MhbLIi s2yPhodenrzrLcLep3Y4VuZG8LOn7MgWkhxnO5CNspQy5/46QeK+x76dThGR8HD6zW a9eajvTUP20e6zWwY/xXCzCuS91P4T8YE4BQ4RwBJnBoTHnqNnojBmOhBsTk87Ihwe +Shw0fNjO2QgnKcWXoRJ3F80sdSSX6r8d6mu0o5WgNledUoJr5oBGwCq0wcnRT4vK1 aZ0lQNpK4oWVkCuUP7FWvTpx4T/klHpnf9ngcFDYY2Cvb+xeLtcFH92lrHvjYNdGht 0iGNRd+NpqLUg== Content-Language: en-US In-Reply-To: <87il36mevf.fsf@yahoo.com> Received-SPF: neutral client-ip=23.83.223.168; envelope-from=adam@alphapapa.net; helo=slateblue.cherry.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_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:315793 Archived-At: Hello Po, > My point was that the circumstances of this change demonstrate that > December's debacle was completely lost on the parties involved. It > should have taught us (again) that users do not take kindly to being > surprised by arbitrary choices a handful of individuals decide to > implement that they were not consulted about, yet within two months of > the event a much more wide-reaching change is installed in an identical > manner, of which criticism is met by an ultimatum to either complete a > task that stands little chance of success (designing and securing the > universal adoption of a new doc string format), or accept the change as > a fact of life. I don't think these two things are comparable. The change to register commands affected users' workflows, i.e. the keypresses they make by habit after many years of usage. Having a change like that appear suddenly is kind of like finding a new pothole in a road one travels every day (although one that shouldn't require a paving machine to fix, being Emacs). Having symbol docstrings be 8 characters wider will probably not affect many users negatively. I'm sure there are a few who have their windows precisely limited to the necessary width; if possible, it would be good to make it easy for them to keep such configuration with pleasant results. 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. > I trust many people will agree with me that increasing this variable > from 64 to 72 is an exclusively aesthetic change, driven by personal > opinions formed towards the appearance of doc strings, and perhaps in > the belief that a lack of change is likely to be perceived as > stagnation. In truth, there has been _nothing_ to suggest that the > width of doc strings has inconvenienced our users in any manner, and > likewise none to suggest widening it will bring about an indispensable > improvement. I don't agree. While I don't feel strongly either way, as one who frequently writes new docstrings, the arbitrary limit is felt. One often must resort to awkward wording or abbreviated variable names to fit within it. And if one doesn't do so, one can't get a clean linting pass. Meanwhile, any window in my Emacs sessions that displays a help buffer has many columns of blank space to the right of the docstrings. And the existing limit is far from being too wide to be read comfortably. > As December's affair should have demonstrated, such arbitrary actions, > when normalized, give rise to a neurotic user-base constantly at each > other's throats, apprehensive of the next update to Emacs which might > break their configurations or interfere with their habits in new and > unseen ways, and belligerent in their defense of their existing > practices and preferences. I mean this literally--Eshel Yaron's blog > post being one example, numerous others exist also, such as the sea of > acrimony formed on Reddit in response to a package developer's request > not to use Emacs 30, which was not so much related to Emacs as it was a > collection of accusations of rudeness, immaturity, and bitter general > faultfinding, or the hostility that radiates from every discussion on > the subject of better or worse defaults, compilation failures induced by > updating to new versions of Emacs, and the like. Worse yet, I can sense > myself warming to them by the hour. I'm not sure how to interpret your characterization of the thread I posted on Reddit. For the record, I was not being critical of the Emacs development process; I was suggesting to users that, unless they want to actively participate in the Emacs development process (i.e. by faithfully reporting bugs that are discovered in unreleased versions), they should use released versions of Emacs; and that they should definitely use only released versions of Emacs when reporting bugs to package developers, because otherwise I can't try to reproduce the reported problems without running such an unreleased version myself. Then, as usual, the discussion went its own way, largely misinterpreting my initial comment, but that's Reddit (and life). > As for Info and "many other things", they are not doc strings, and > should not be factors in decisions regarding them. 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. --Adam