GNU bug report logs - #77123
29.1; call-next-method

Previous Next

Package: emacs;

Reported by: Christopher Stacy <cstacy <at> dtpq.com>

Date: Wed, 19 Mar 2025 18:21:02 UTC

Severity: normal

Found in version 29.1

Fixed in version 30.1

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Christopher Stacy <cstacy <at> dtpq.com>
Cc: 77123 <at> debbugs.gnu.org, Eric Ludlam <zappo <at> gnu.org>
Subject: Re: 29.1; call-next-method
Date: Wed, 19 Mar 2025 17:00:08 -0400
> Attached is an example test program,
> including test results. There are two
> versions: one for Emacs Lisp,
> and one is for Common Lisp (CLOS).
> CL does it correctly (of course),
> but EL gets the wrong answer.

I couldn't make your test work as is, but I used the adjusted file below
and it gives me:

    % /usr/bin/emacs -Q --batch -l ~/tmp/foo.el
    (base alpha beta winner)
    (base beta alpha glop flop)
    %

which seems to match your CLOS expectation.  But that was with Debian
testing's Emacs-30.  I don't have an Emacs-29 handy, so I used Debian
stable's Emacs-28.2 and indeed there I see your problem:

    % /usr/bin/emacs -Q --batch -l ~/tmp/foo.el
    (base alpha beta winner)
    (base glop flop)
    %

So, AFAICT this is already fixed in Emacs-30.  I did rework the way the
hierarchy is flattened (to share it with the same code used for major
mode hierarchies, resulting in the new function 'merge-ordered-lists'),
so that's not completely surprising, tho I can't remember noticing that
it would fix a bug.


        Stefan





This bug report was last modified 87 days ago.

Previous Next


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