From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63236: 29.0.90; loaddefs-generate not 100% backwards compatible Date: Wed, 03 May 2023 18:50:20 +0300 Message-ID: <83354dmn2b.fsf@gnu.org> References: <87cz3ill2x.fsf@gmail.com> <871qjxlseb.fsf@gmail.com> <83bkj1mzj2.fsf@gnu.org> <87wn1pjzme.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4849"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63236@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 03 17:50:18 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1puEkE-00014d-6f for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 May 2023 17:50:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1puEk0-0005b3-EP; Wed, 03 May 2023 11:50:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1puEjz-0005af-2G for bug-gnu-emacs@gnu.org; Wed, 03 May 2023 11:50:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1puEjy-00033t-IK for bug-gnu-emacs@gnu.org; Wed, 03 May 2023 11:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1puEjy-0008NX-A0 for bug-gnu-emacs@gnu.org; Wed, 03 May 2023 11:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 May 2023 15:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63236 X-GNU-PR-Package: emacs Original-Received: via spool by 63236-submit@debbugs.gnu.org id=B63236.168312898132169 (code B ref 63236); Wed, 03 May 2023 15:50:02 +0000 Original-Received: (at 63236) by debbugs.gnu.org; 3 May 2023 15:49:41 +0000 Original-Received: from localhost ([127.0.0.1]:47553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1puEjd-0008Mn-F8 for submit@debbugs.gnu.org; Wed, 03 May 2023 11:49:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50446) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1puEjZ-0008MX-Ft for 63236@debbugs.gnu.org; Wed, 03 May 2023 11:49:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1puEjU-00030X-4M; Wed, 03 May 2023 11:49:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=EFKfJEF8xNdTeZXL8P2PJKaPrrM/e6xIFWYTvJ9HH9c=; b=B/IJ6h1CYbNHryKOa2oi ts3dpQ+G4glXw19zdBtiHTPPOshoUL1oUHivfa9kniL2x2h/Dti17NgZZ0UDuoSYizVFr7EgpkVrK pswy6c9N1HX+onOJLJ8D0dEwTCv0xO1N0oSmOjA/vCSnvJSJ72VQsHI0d+ZGl56V2S8h2lDiRC55R A9v4weIHTl5Op/yxZcrUT4+Js9v41eyJceJCY6rFHCALvL9jyxzcFFtMOJy9NEKkj/nm/H3jW2Ovk 09u2oI0NNWcD0h/2TvNAcJFpleSAB108HZVk7wf3i4i7IDFa5UKxkYZm7Nmdlz9I6NYnhES3Xufei eXUYD561TMfgJw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1puEjT-0006Yf-Cx; Wed, 03 May 2023 11:49:31 -0400 In-Reply-To: <87wn1pjzme.fsf@gmail.com> (message from Robert Pluim on Wed, 03 May 2023 15:47:21 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260983 Archived-At: > From: Robert Pluim > Cc: 63236@debbugs.gnu.org > Date: Wed, 03 May 2023 15:47:21 +0200 > > >>>>> On Wed, 03 May 2023 14:21:05 +0300, Eli Zaretskii said: > > >> From: Robert Pluim > >> Date: Wed, 03 May 2023 10:40:28 +0200 > >> > >> >>>>> On Tue, 02 May 2023 19:06:14 +0200, Robert Pluim said: > >> > Robert> I attempted to upgrade my packages today using `list-packages', which > Robert> errored out when regenerating the autoloads for vlf-write.el: > >> > Robert> Debugger entered--Lisp error: (search-failed "\n\f\n;;;") > Robert> search-forward("\n\f\n;;;") > Robert> loaddefs-generate("/home/rpluim/.emacs.d/elpa/vlf-20191126.2250" "/home/rpluim/.emacs.d/elpa/vlf-20191126.2250/vlf-a..." nil "(add-to-list 'load-path (or (and load-file-name (f...") > Robert> package-generate-autoloads(vlf "/home/rpluim/.emacs.d/elpa/vlf-20191126.2250") > >> > >> The minimal patch I can come up with is this, which seems safe enough > >> but Iʼd appreciate it if someone who knows the code could comment > > Eli> Can you describe what was special in your use case, and explain why > Eli> the original code didn't work in that case? > > Itʼs not the use case thatʼs special, itʼs the package I was installing: > The autoloads file shipped with vlf-20191126.2250 didnʼt have a line > starting with ';;;' after the final entry in the file, which is what > the code was looking for. But if the search for "\n\f\n;;;" fails, why should we assume that the search for "\n\f\n;;" will succeed? A broken autoloads file can be broken in a much worse manner, no? Is even a form-feed guaranteed? Maybe we should assume, if the search for the canonical last line fails, that there's no canonical last line, and just insert it ourselves? What did the old code do in these cases? > Looking at the history, the autoloads generation was rewritten for > emacs-29, so this looks like a minor regression. Yes, loaddefs-gen.el is new, so we must fix it on the emacs-29 branch.