From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxim Cournoyer Newsgroups: gmane.emacs.bugs Subject: bug#56197: 28.1; lisp-fill-paragraph result regressed with Emacs 28 Date: Sun, 29 Dec 2024 00:14:50 +0900 Message-ID: <87ttanrg9h.fsf@gmail.com> References: <87zgi2xcgm.fsf@gmail.com> <87y1xlj6wn.fsf@gnus.org> <834k08c3se.fsf@gnu.org> <874k08kj31.fsf@gnus.org> <87y1xkj4co.fsf@gnus.org> <87tu88j3tf.fsf@gnus.org> <87bjwzr027.fsf@lease-up.com> <86v7v7ynf0.fsf@gnu.org> <87seq8tm2f.fsf@gmail.com> <86o70wurf9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39329"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: larsi@gnus.org, 56197@debbugs.gnu.org, felix.lechner@lease-up.com, stefankangas@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 28 16:17:23 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1tRYZ8-000A5R-6O for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Dec 2024 16:17:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRYYr-0000Z2-2y; Sat, 28 Dec 2024 10:17:05 -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 1tRYYo-0000Yp-EI for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2024 10:17:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tRYYo-0005KK-5N for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2024 10:17:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=sY1WvmByA0/ApcHrDskEBDFjbfkTT0AqmCPgQEe/R/c=; b=UcFJ8+PyMunaR1jLp4vUugono3gbXMwMKppawtzVmZfSusjy3mrtMPGhLqRdqMndyp9KxC4CyiuOzx7mTaS5sDbZW+R/plo0TAFsg+22BRs/GuIn+hyYgQICr5I81g3Zhl/AEBQPTLr+gcyZV7dd5c04KOAmz+W0xNZpl2ckQFzbVi0T8UPRHAvLIu/PBEa6gX5J2Ipu3Gp0irVTMiryuPz4qoJJQ6bdbwffBVS4i+QcKeCYJWWZTfId2omhXwFiD99dGG/2cNcMu0l5Rf1DbHUF0Q6p0ZJRrgcxwZKReTMepEmAt3OWNtp4rmeG2Do02xxF0Oopz3Gp8tKGcfHCQA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tRYYn-0002EL-PD for bug-gnu-emacs@gnu.org; Sat, 28 Dec 2024 10:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Dec 2024 15:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56197 X-GNU-PR-Package: emacs Original-Received: via spool by 56197-submit@debbugs.gnu.org id=B56197.17353989708488 (code B ref 56197); Sat, 28 Dec 2024 15:17:01 +0000 Original-Received: (at 56197) by debbugs.gnu.org; 28 Dec 2024 15:16:10 +0000 Original-Received: from localhost ([127.0.0.1]:52294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tRYXx-0002Cp-Qt for submit@debbugs.gnu.org; Sat, 28 Dec 2024 10:16:10 -0500 Original-Received: from mail-pl1-f173.google.com ([209.85.214.173]:55457) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tRYXv-0002Cb-Pr for 56197@debbugs.gnu.org; Sat, 28 Dec 2024 10:16:09 -0500 Original-Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-21636268e43so38318405ad.2 for <56197@debbugs.gnu.org>; Sat, 28 Dec 2024 07:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735398902; x=1736003702; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=sY1WvmByA0/ApcHrDskEBDFjbfkTT0AqmCPgQEe/R/c=; b=fxhwwq90rCyxjTL1jqdUNiHSMmxapSmpujnj99qvhjz/Iq+aQFsNW8swft6biLTV/7 zNw/XT31LgASHdJ38m2TMUi9XAXM6RWdv9N+R5mFywKzVQq9dkn8icpDJJAXdBkKCQtv e+ezjjxCTDHRKodbZf+EdtLB2rhpsFC36EW+7nM5kX9EWLfOHC5Ji+RUV+Ab2MMbwxhM Ub7otUL24z4pLHHqI+q+my0YJA9FTA13uYe8KvkdJX2WRrEQIG9gmkGKBzYb+E4opiQK /r2p5gHZ+V9En18P4COwI7HMiq42mFJjtOVhFbTOp7IHo92zQQe26/Tdr8sDVxs16xll sOPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735398902; x=1736003702; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=sY1WvmByA0/ApcHrDskEBDFjbfkTT0AqmCPgQEe/R/c=; b=JRFfpJkUkU+stSz6Akd4gIAcdQDDqoiPJbao+JjzE7v5XuIAiXwd7H8TfcSgtv386F +FgR28QuYqVWPdvmU1+5obHFHeF1VR0VCNwO9J/ZshaxOEko+Ofi5S9Wv/XCgZGY9cdV LLKNTHznsRd5QRNanOjgoBFvzDYzVtryQsyvcq6yXtNw3vUl8rTqRVuhuEP0btoPTXs5 oGdMrq+k2lDAy8l3rzqx+DiU8cuJqgKBh54f7CqevjuCVaoYlwjW57BdhxwDyuJDPiB+ FME4vMZv66OAfRJ5xl+DbqM4kfGtDs+jaUYOmUc3DVmzSQGweUr8Mlxj5NUdKbI9L2EF QRSg== X-Forwarded-Encrypted: i=1; AJvYcCV8juCnYEeHakqFuYIQbONj4n/sYK1GywUPMfqHn9WptZSobdeTjVUzX+UsyCIRrin/vCmPxA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyodWUKfei6qjQcayk3B6vr3/24gR8X/HWqR9fFmZ2pldsGProh +KisMbEFieSIxXvNseiSlpoFalx7JTzO5wi5hO0+h8sAVUZgI+G9RMp/eOWAf1k= X-Gm-Gg: ASbGnctZIE/LyJimgl29F+utkMqR6VYRE6aY5BsdtnrthpbEjezrm2ssKCbkpUHaxgv /1496c/2vHhqcGau+GPV4ne6/Ka7MMoHfQ/a6U+jEbXp0Gtj9MAXmCg051/DhHXHm8tVTdzniim iYYuZeZnMF58QkqR/oZtyvXhlz6DSlCuDoRlFEIvjkx5J8GhtXSnrCr30MnCoGY2V1imA9otXjQ GDp3AqGb0wKqGxtkBv2DGFso4vfBCzjhygjJh01a5PT5SDOtMrGxQ== X-Google-Smtp-Source: AGHT+IGP8YaK2jAW1mWzaHrsWnRtNQIC6owjsDYsWRuZ4Ij2pWJ9ZShlTntVGJPnvtX3OK6AQYWfKw== X-Received: by 2002:a17:903:3205:b0:215:b9a7:526d with SMTP id d9443c01a7336-219e6ecfbb4mr448916715ad.32.1735398902116; Sat, 28 Dec 2024 07:15:02 -0800 (PST) Original-Received: from terra ([2405:6586:be0:0:c8ff:1707:9b9:af89]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-219dc962c75sm151181015ad.24.2024.12.28.07.14.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Dec 2024 07:15:01 -0800 (PST) In-Reply-To: <86o70wurf9.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 28 Dec 2024 10:45:30 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:297910 Archived-At: Hello, Eli Zaretskii writes: >> From: Maxim Cournoyer >> Cc: Felix Lechner , 56197@debbugs.gnu.org, >> stefankangas@gmail.com, larsi@gnus.org >> Date: Sat, 28 Dec 2024 14:26:32 +0900 >> >> I can't say it feels very satisfactory; a switch like one imagined by >> Felix could be a step in the right direction; it'd be at least more >> concise in the project .dir-locals. Would a patch implementing that be >> welcome? > > I don't see how a user option to control this could be useful, since > the preferred behavior is not only buffer-local, but also specific to > certain syntactic constructs. But I won't object to having such an > option. Having the behavior defined per-project or even globally (reverting to the the pre-Emacs 28 behavior) via a simple option seems like it'd simplify things, and make them discoverable. > I also don't see what's wrong with the solution of having a special > function in .dir-locals.el. We don't pretend that the default Emacs > behavior should necessarily fit all the use cases, and provide ample > opportunities for customizing Emacs behavior for that reason. > Defining a custom fill-paragraph function is a perfectly valid > solution, not very different from having a user option for the same > purpose. So I'm not sure I understand why you prefer adding an > option, when the Guix project has already solved the problem in a > perfectly legitimate and clean way. For one, having to put that largish piece of evaluated code in the .dir-locals.el of the project means each new developer is prompted to trust it, and it makes it more intimidating/pollutes their user conf file (being added to the 'safe-local-variable-values' value). It's also not discoverable; a customizable option would help in this regard. -- Thanks, Maxim