GNU bug report logs - #71654
[PATCH] Fix display-buffer-override-next-command

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71654 in the body.
You can then email your comments to 71654 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "kassick <at> gmail.com" <kassick <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Fix display-buffer-override-next-command
Date: Wed, 19 Jun 2024 12:20:19 -0300

[Message part 1 (text/plain, inline)]

When display-buffer-overriding-action's car is set to a function instead of
a list, display-buffer-override-next-command must ensure that the car is a
list before pushing a new element to it, otherwise the car will become a
itself a cons-cell and the clear-fun will trigger a wrong-type-argumen
error when trying to delq the action.

The error can be triggered by using some minor mode that
updates display-buffer-override-next-command (such as purpose-mode) and
then calling other-window-prefix.

The patch was created using the `emacs-29` branch.

----

In GNU Emacs 29.3.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2024-05-27 built on thnkpd
System Description: Fedora Linux 39 (Workstation Edition)

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr/local
 --sharedstatedir=/var/lib --localstatedir=/var/lib --enable-libsystemd
 --with-pop=yes --build x86_64-linux-gnu
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --with-cairo
 --with-x=yes --with-x-toolkit=gtk3 --with-pgtk
 --with-toolkit-scroll-bars --without-xwidgets --with-imagemagick
 --with-native-compilation --with-tree-sitter --with-xinput2'

-- 
Rodrigo Virote Kassick
------------------------------------------------------------

[Message part 2 (text/html, inline)]

[0001-Fix-display-buffer-override-next-command.patch (text/x-patch, attachment)]

Message #8 received at 71654 <at> debbugs.gnu.org (full text, mbox):

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: kassick <at> gmail.com
Cc: 71654 <at> debbugs.gnu.org
Subject: Re: bug#71654: [PATCH] Fix display-buffer-override-next-command
Date: Wed, 19 Jun 2024 22:17:51 +0100

"kassick <at> gmail.com" <kassick <at> gmail.com> writes:

> When display-buffer-overriding-action's car is set to a function
> instead of a list, display-buffer-override-next-command must ensure
> that the car is a list before pushing a new element to it, otherwise
> the car will become a itself a cons-cell and the clear-fun will
> trigger a wrong-type-argumen error when trying to delq the action.
>
> The error can be triggered by using some minor mode that
> updates display-buffer-override-next-command (such as purpose-mode)
> and then calling other-window-prefix.
>

To reproduce the bug, what other built-in modes (instead of
purpose-mode) can be used?

Message #13 received at 71654-done <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: kassick <at> gmail.com
Cc: 71654-done <at> debbugs.gnu.org
Subject: Re: bug#71654: [PATCH] Fix display-buffer-override-next-command
Date: Wed, 19 Jun 2024 17:32:01 -0400

"kassick <at> gmail.com" <kassick <at> gmail.com> writes:

> When display-buffer-overriding-action's car is set to a function instead of a list, display-buffer-override-next-command
> must ensure that the car is a list before pushing a new element to it, otherwise the car will become a itself a cons-cell
> and the clear-fun will trigger a wrong-type-argumen error when trying to delq the action.
>
> The error can be triggered by using some minor mode that updates display-buffer-override-next-command (such as
> purpose-mode) and then calling other-window-prefix.

Hi Rodrigo,

the patch LGTM so I applied it after some indentation massage to master.

Closing then, happy to reopen if some more work is needed.

Thanks

  Andrea

Message #16 received at 71654-done <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: kassick <at> gmail.com
Cc: 71654-done <at> debbugs.gnu.org
Subject: Re: bug#71654: [PATCH] Fix display-buffer-override-next-command
Date: Wed, 19 Jun 2024 18:11:27 -0400

"kassick <at> gmail.com" <kassick <at> gmail.com> writes:

> Awesome!
>
> Any chance of cherry-picking it on emacs-29?

We could do that if we feel sure this has no implications, but there
will be no more emacs 29 releases anyway and we are about to branch 30,
so I'm not sure it's worth of even if the change looks simple.

  Andrea

Message #19 received at 71654 <at> debbugs.gnu.org (full text, mbox):

From: "kassick <at> gmail.com" <kassick <at> gmail.com>
To: Jeremy Bryant <jb <at> jeremybryant.net>
Cc: 71654 <at> debbugs.gnu.org
Subject: Re: bug#71654: [PATCH] Fix display-buffer-override-next-command
Date: Wed, 19 Jun 2024 18:53:08 -0300

[Message part 1 (text/plain, inline)]

No need for any mode, just

- M-S-:  (setq display-buffer-overriding-action (cons #'ignore nil))
RET      ;; Eval
- C-x 4 4   ;;  (other-window-prefix)
- C-x C-f  ;; (find-file)

and you should already see the error.

After that, you probably will end up with an unusable emacs, so just eval
(setq display-buffer-overriding-action (cons nil nil)) and you'll be good
to go.

Em qua., 19 de jun. de 2024 às 18:17, Jeremy Bryant <jb <at> jeremybryant.net>
escreveu:

> "kassick <at> gmail.com" <kassick <at> gmail.com> writes:
>
> > When display-buffer-overriding-action's car is set to a function
> > instead of a list, display-buffer-override-next-command must ensure
> > that the car is a list before pushing a new element to it, otherwise
> > the car will become a itself a cons-cell and the clear-fun will
> > trigger a wrong-type-argumen error when trying to delq the action.
> >
> > The error can be triggered by using some minor mode that
> > updates display-buffer-override-next-command (such as purpose-mode)
> > and then calling other-window-prefix.
> >
>
> To reproduce the bug, what other built-in modes (instead of
> purpose-mode) can be used?
>


-- 
Rodrigo Virote Kassick
------------------------------------------------------------

[Message part 2 (text/html, inline)]

Message #22 received at 71654-done <at> debbugs.gnu.org (full text, mbox):

From: "kassick <at> gmail.com" <kassick <at> gmail.com>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: 71654-done <at> debbugs.gnu.org
Subject: Re: bug#71654: [PATCH] Fix display-buffer-override-next-command
Date: Wed, 19 Jun 2024 18:54:35 -0300

[Message part 1 (text/plain, inline)]

Awesome!

Any chance of cherry-picking it on emacs-29?

Em qua., 19 de jun. de 2024 às 18:32, Andrea Corallo <acorallo <at> gnu.org>
escreveu:

> "kassick <at> gmail.com" <kassick <at> gmail.com> writes:
>
> > When display-buffer-overriding-action's car is set to a function instead
> of a list, display-buffer-override-next-command
> > must ensure that the car is a list before pushing a new element to it,
> otherwise the car will become a itself a cons-cell
> > and the clear-fun will trigger a wrong-type-argumen error when trying to
> delq the action.
> >
> > The error can be triggered by using some minor mode that updates
> display-buffer-override-next-command (such as
> > purpose-mode) and then calling other-window-prefix.
>
> Hi Rodrigo,
>
> the patch LGTM so I applied it after some indentation massage to master.
>
> Closing then, happy to reopen if some more work is needed.
>
> Thanks
>
>   Andrea
>


-- 
Rodrigo Virote Kassick
------------------------------------------------------------

[Message part 2 (text/html, inline)]

Message #25 received at 71654-done <at> debbugs.gnu.org (full text, mbox):

From: "kassick <at> gmail.com" <kassick <at> gmail.com>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: 71654-done <at> debbugs.gnu.org
Subject: Re: bug#71654: [PATCH] Fix display-buffer-override-next-command
Date: Wed, 19 Jun 2024 19:16:13 -0300

[Message part 1 (text/plain, inline)]

Ah, time for me to update here, then!

Anyone having this issue in 29 or older could just use advice to patch the
function and move on, don't see any reason to backport it.



Em qua., 19 de jun. de 2024 às 19:11, Andrea Corallo <acorallo <at> gnu.org>
escreveu:

> "kassick <at> gmail.com" <kassick <at> gmail.com> writes:
>
> > Awesome!
> >
> > Any chance of cherry-picking it on emacs-29?
>
> We could do that if we feel sure this has no implications, but there
> will be no more emacs 29 releases anyway and we are about to branch 30,
> so I'm not sure it's worth of even if the change looks simple.
>
>   Andrea
>


-- 
Rodrigo Virote Kassick
------------------------------------------------------------

[Message part 2 (text/html, inline)]

Message #28 received at 71654 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: 71654 <at> debbugs.gnu.org, kassick <at> gmail.com
Subject: Re: bug#71654: [PATCH] Fix display-buffer-override-next-command
Date: Thu, 20 Jun 2024 08:15:14 +0300

> Cc: 71654-done <at> debbugs.gnu.org
> From: Andrea Corallo <acorallo <at> gnu.org>
> Date: Wed, 19 Jun 2024 18:11:27 -0400
> 
> "kassick <at> gmail.com" <kassick <at> gmail.com> writes:
> 
> > Awesome!
> >
> > Any chance of cherry-picking it on emacs-29?
> 
> We could do that if we feel sure this has no implications, but there
> will be no more emacs 29 releases anyway and we are about to branch 30,
> so I'm not sure it's worth of even if the change looks simple.

Agreed.

Message #31 received at 71654-done <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: kassick <at> gmail.com
Cc: 71654-done <at> debbugs.gnu.org
Subject: Re: bug#71654: [PATCH] Fix display-buffer-override-next-command
Date: Thu, 20 Jun 2024 03:55:54 -0400

"kassick <at> gmail.com" <kassick <at> gmail.com> writes:

> Ah, time for me to update here, then!
>
> Anyone having this issue in 29 or older could just use advice to patch the function and move on, don't see any reason to
> backport it.

BTW for this we could rely on the copyright paperwork exempt because the
change was tiny, but if in the future you plan to contribute more to
Emacs might be good to do the FSF copyright paperwork so we are covered.

In case please let me know and I can send you the form.

Thanks for your contribution.

  Andrea

Previous Next

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