GNU bug report logs - #63236
29.0.90; loaddefs-generate not 100% backwards compatible

Previous Next

Full log

View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63236 <at> debbugs.gnu.org
Subject: bug#63236: 29.0.90; loaddefs-generate not 100% backwards compatible
Date: Thu, 04 May 2023 10:45:37 +0200

>>>>> On Wed, 03 May 2023 18:50:20 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
    Eli> But if the search for "\n\f\n;;;" fails, why should we assume that the
    Eli> search for "\n\f\n;;" will succeed?  A broken autoloads file can be
    Eli> broken in a much worse manner, no?  Is even a form-feed guaranteed?

Nothing is guaranteed, but in the only example in the wild Iʼve found where the
emacs-29 code fails, searching for only two ';' works.

    Eli> Maybe we should assume, if the search for the canonical last line
    Eli> fails, that there's no canonical last line, and just insert it
    Eli> ourselves?

Yes, but the issue here is that the code is deciding where to end the
region that itʼs deleting from an existing autoloads file. If we donʼt
do the deletion, we get duplicate entries (or maybe even a broken
autoloads file).

    Eli> What did the old code do in these cases?

Iʼm not sure. A quick read of emacs-lisp/autoloads.el in emacs-28
seems to indicate itʼs looking for ';', but I havenʼt actually tested
it.

    >> Looking at the history, the autoloads generation was rewritten for
    >> emacs-29, so this looks like a minor regression.

    Eli> Yes, loaddefs-gen.el is new, so we must fix it on the emacs-29 branch.

Then the easiest fix would be to search for two ';' instead of three.

Robert
-- 

Previous Next

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