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: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56197 <at> debbugs.gnu.org, maxim.cournoyer <at> gmail.com
Subject: bug#56197: 28.1; lisp-fill-paragraph result regressed with Emacs 28
Date: Sat, 25 Jun 2022 15:42:57 +0300
> Cc: 56197 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 25 Jun 2022 13:53:44 +0200
> 
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> 
> > ;; Emacs 28
> >     (description "IBus-Anthy is an engine for the input bus \"IBus\").  It adds the Anthy
> > Japanese language input method to IBus.  Because most graphical applications
> > allow text input via IBus, installing this package will enable Japanese
> > language input in most graphical applications.")
> 
> [...]
> 
> > Simply commenting out the newly added block, evaluating the defun and
> > running it on my example reverts to the previous correct behavior.
> 
> I'm not sure the previous behaviour was any more correct.  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", which is wrong in most
> contexts.
> 
> So I don't know.  Anybody have an opinion?

I actually don't understand what kind of "Lisp code" is the above
snippet.  It doesn't look to me as valid Lisp code.  So there's no
criteria for judging the correctness here, it seems.




This bug report was last modified 109 days ago.

Previous Next


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