From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56197: 28.1; lisp-fill-paragraph result regressed with Emacs 28 Date: Thu, 26 Dec 2024 08:21:39 +0200 Message-ID: <86v7v7ynf0.fsf@gnu.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38243"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 56197@debbugs.gnu.org, maxim.cournoyer@gmail.com, stefankangas@gmail.com To: Felix Lechner Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 26 07:22:22 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 1tQhGH-0009nd-4I for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Dec 2024 07:22:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQhG1-0007k3-08; Thu, 26 Dec 2024 01:22: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 1tQhFz-0007ja-AL for bug-gnu-emacs@gnu.org; Thu, 26 Dec 2024 01:22: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 1tQhFy-0004tX-5y for bug-gnu-emacs@gnu.org; Thu, 26 Dec 2024 01:22: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:References:In-Reply-To:From:Date:To:Subject; bh=C/lbmb9IGwXJhZMSL0nv3+0nx6lAe+AFqjIn5YimIx0=; b=Wu2Igg7osUubCWm27W+8OIXB5F+iggJ7lzNejJqNApJaxSydIbNHUyqj2EIrETCyROXRkYKsvWUsNMq+7UQl045dUk3gMWqlWA1y+SoJy9+0/CCe0kEr4j/p3ZldM1cXcTZDZnQkz2ofb1AtX9rUx7dcyQ1P2KDRNxj95kS8Qd2coUSGRp4ONMLJK9ibYLKtR5Lt/sAuEcCi7PW1nDx5rQI9DmyLRvDa53hLeG2XSJDkUNLa+C8b8gU4y5oaeCvzp4qSdQRgNJOv8txxewmdM34FfL0UooiVfshU1YUv83Rcs2WIU5tQt9YjNNQOIuSlknmywQataM7QiPp47JrRQA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tQhFx-0002tD-Or for bug-gnu-emacs@gnu.org; Thu, 26 Dec 2024 01:22:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Dec 2024 06:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56197 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: pending Original-Received: via spool by 56197-submit@debbugs.gnu.org id=B56197.173519411311075 (code B ref 56197); Thu, 26 Dec 2024 06:22:01 +0000 Original-Received: (at 56197) by debbugs.gnu.org; 26 Dec 2024 06:21:53 +0000 Original-Received: from localhost ([127.0.0.1]:39828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tQhFo-0002sZ-Fi for submit@debbugs.gnu.org; Thu, 26 Dec 2024 01:21:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tQhFl-0002sF-SL for 56197@debbugs.gnu.org; Thu, 26 Dec 2024 01:21:50 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQhFf-0004sB-07; Thu, 26 Dec 2024 01:21:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=C/lbmb9IGwXJhZMSL0nv3+0nx6lAe+AFqjIn5YimIx0=; b=CO/+b9z1hs3d1XJ5PQ2u 2rtXAXe7Wq4VSMGQGxNiNt5RR92ibgS/bWFecAQGJvdALuHYe2cF5pyxDk+fegkebXAIz6QOhHMG9 xEtR6MNZHV9LItF0RCHbNexuuLnrdjZTXS/6QHdTy1j5xJop1ILH2/+KgHyW+fV4ZQNiqXzAZt8fV cPPAL8v4EnnDjgenaPg2tgt2gRMx2FQnwipQlENr458o9wL5WcZB0Xh0RCRl7Feli7EJzcPPKlHwo t0e6T+dNfMYn5i+XoYHUGSAn/1hJyFm2rCbwP3OvUR0tR1LiWcEu8RuVnvn6LgViF/udaBVRZhCFq 30FP2u3Nd1HzHQ==; In-Reply-To: <87bjwzr027.fsf@lease-up.com> (message from Felix Lechner on Wed, 25 Dec 2024 12:15:44 -0800) 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:297749 Archived-At: > From: Felix Lechner > Cc: Maxim Cournoyer , Stefan Kangas > , Eli Zaretskii , Lars Ingebrigtsen > > Date: Wed, 25 Dec 2024 12:15:44 -0800 > > > fill the string using fill-column, or [...] fill the text as is in the > > buffer > > > It's now filling that string as if it, well, is a string, so that if > > you insert it somewhere, the lines have similar lengths. The previous > > behaviour was to fill "what you see in the buffer" > > > The former sounds more useful, IMO. I don't want to mess up my strings > > just to have pretty source code > > Filling strings in code would be useful, but isn't that a separate, > don't-break-my-strings feature? Not necessarily. I frequently fill stuff in my code, and don't want to use a separate command if the region I fill includes strings (or comments, or something other that needs special filling behavior). > Historically, the point of text justification is to make text fit on a > screen. For example, the documentation for fill-region refers to > columns, which are features of buffers: > > Column beyond which automatic line-wrapping should happen. > > Auto-fill-mode is consistent: > > inserting a space at a column beyond current-fill-column > automatically breaks the line > > In a grand sweep, the manual explains what needs to fit where: > > “Filling” text means breaking it up into lines that fit a specified > width. > > Section 26.6.2 ("Explicit Fill Commands") is even more, well, explicit: > > The command ‘M-q’ (‘fill-paragraph’) “fills” the current paragraph. > It redistributes the line breaks within the paragraph, and deletes > any excess space and tab characters occurring within the paragraph, > in such a way that the lines end up fitting within a certain maximum > width. > > How text shows on a screen is clearly a central feature. The manual > continues: > > The maximum line width for filling is specified by the buffer-local > variable ‘fill-column’. The default value (*note Locals::) is 70. > The easiest way to set ‘fill-column’ in the current buffer is to use > the command ‘C-x f’ (‘set-fill-column’). [...] Note that, by its > very nature, ‘fill-column’ is measured in column units; the actual > position of that column on a graphical display depends on the font > being used. In particular, using variable-pitch fonts will cause > the ‘fill-column’ occupy different horizontal positions on display > in different lines. > > In my view, the string interpretation calls for a different, though > related feature. You are quoting text which talks about the _default_ filling. The default filling is tailored to "uniform" text, i.e. really to Text mode and its descendants. However, Emacs lets major modes customize filling as appropriate for the mode, by defining mode-specific filling functions. Which is what happens in this case: lisp-mode.el defines a fill-paragraph function that is specific to Lisp modes. It is completely legitimate for such mode-specific functions to special-case strings inside code and do something special about that. So I don't see how what we do now is against the spirit of filling. (Btw, I think it's high time we closed that bug, since Emacs 28.2 was released long ago.)