GNU bug report logs - #56197
lisp-fill-paragraph behavior changed in Emacs 28

Previous Next

Package: emacs;

Reported by: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Date: Fri, 24 Jun 2022 16:18:01 UTC

Severity: normal

Tags: patch

Found in version 28.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 56197 <at> debbugs.gnu.org, felix.lechner <at> lease-up.com, stefankangas <at> gmail.com
Subject: bug#56197: [PATCH v3] lisp: Introduce a `lisp-fill-paragraph-as-displayed' variable.
Date: Tue, 28 Jan 2025 22:45:28 +0900
Hi Eli,

Eli Zaretskii <eliz <at> gnu.org> writes:

[...]

>> > I'm okay with looking for a better name, but
>> > fill-strings-instead-of-paragraphs doesn't sound like a better one
>> > (and "terrible" is an exaggeration, IMO).  How about
>> > fill-paragraph-as-doc-string, by default t?
>> 
>> That's not a bad name, but my code simply avoids narrowing to strings,
>> it preserves the special handling for doc strings such as filling the
>> first sentence separately to the second one, so it wouldn't be accurate
>> in the current version.  We could also turn this special handling off
>> (which would also be welcome in my use case), then your suggested naming
>> would make sense.
>
> Sorry, I don't follow.  The behavior introduced in Emacs 28 was to
> fill the paragraph as if it were a doc string, treating the first line
> specially.  Setting the new variable you added disables that.  That is
> why I said the variable should be t by default; disabling the new
> behavior would then mean resetting it to nil.
>
> So what am I missing?

Apologies for the confusion, I re-verified and indeed the special
handling of the first line/second line is also disabled by the new
'lisp-fill-paragraph-as-displayed' variable I added (when t).  That's
one of two things it does, the other one (which was causing the
protruding fill-column behavior) is the narrowing to the string being
filled.  This puts the string alone in a temp buffer and fills it there,
which means there's no indentation anymore, which in turns causes the
protruding of fill-column.

I'm talking about this piece of code:

--8<---------------cut here---------------start------------->8---
                  (when (ppss-string-terminator ppss)
                    (goto-char string-start)
                    ;; The string may be unterminated -- in that case, don't
                    ;; narrow.
                    (when (ignore-errors
                            (prong
                              (forward-sexp 1)
                              t))
                      (narrow-to-region (1+ string-start)
                                        (1- (point)))))
--8<---------------cut here---------------end--------------->8---

That's why I chose the name 'as-displayed', meaning preserve surrounding
context and do not narrow to the string.

With that said, I don't feel strongly about it, so if both Felix and you
feel like 'fill-paragraph-as-doc-string' is more accurate/clear, please
proceed :-).

-- 
Thanks,
Maxim




This bug report was last modified 158 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.