unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Robert Pluim <rpluim@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 63236@debbugs.gnu.org
Subject: bug#63236: 29.0.90; loaddefs-generate not 100% backwards compatible
Date: Thu, 04 May 2023 10:45:37 +0200	[thread overview]
Message-ID: <87lei4jxhq.fsf@gmail.com> (raw)
In-Reply-To: <83354dmn2b.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 May 2023 18:50:20 +0300")

>>>>> On Wed, 03 May 2023 18:50:20 +0300, Eli Zaretskii <eliz@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
-- 





  reply	other threads:[~2023-05-04  8:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-02 17:06 bug#63236: 29.0.90; loaddefs-generate not 100% backwards compatible Robert Pluim
2023-05-03  8:40 ` Robert Pluim
2023-05-03  8:48   ` Andreas Schwab
2023-05-03 11:21   ` Eli Zaretskii
2023-05-03 13:47     ` Robert Pluim
2023-05-03 15:02       ` Robert Pluim
2023-05-03 15:50       ` Eli Zaretskii
2023-05-04  8:45         ` Robert Pluim [this message]
2023-05-04 10:42           ` Eli Zaretskii
2023-05-04 14:04             ` Robert Pluim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lei4jxhq.fsf@gmail.com \
    --to=rpluim@gmail.com \
    --cc=63236@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).