[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags
From: |
Ingo Lohmar |
Subject: |
bug#51270: 28.0.50; xref core package 1.3.0 published, breaks etags |
Date: |
Mon, 18 Oct 2021 21:12:37 +0000 |
On Mon, Oct 18 2021 23:38 (+0300), Dmitry Gutov wrote:
>> The breakage happens because xref 1.3.0 has been published on GNU ELPA
>> https://elpa.gnu.org/packages/ (although the details page shows 1.2.2 as
>> the latest version, don't know why). I am using the "eglot" package,
>> which requires xref (at a lower minimum version), and when upgrading
>> packages this morning, I got xref 1.3.0.
>
> Which version of Emacs are you using? I understand Emacs 26 might have a
> problem with :noinline instructions in the new struct definitions.
I am using the feature/pgtk branch, which is currently based on an older
master (roughly 3m ago) it seems.
> But as for loading eieio and defining the xref-location class, the
> top-level version check at the beginning of xref.el should supposedly
> help. It looks like:
>
> (eval-and-compile
> (when (version< emacs-version "28")
> ;; etags.el in Emacs 26 and 27 uses EIEIO, and its location type
> ;; inherits from `xref-location'.
> (require 'eieio)
> (with-no-warnings
> (defclass xref-location () ()
> :documentation "..."))))
Ah, I did not look at the 1.3.0 file. So the above will help for all
released emacs versions, but will just not run for a non-recent master
of Emacs 28, get it.
I don't have a backtrace yet, but can provide one if it's helpful for
related questions. I guess I will just manually move xref-1.3.0 out of
the way until I can update to a newer Emacs master (which will then
include the coordinated xref/etags changes).
Yeah, the packaging story is not really robust yet. I only mentioned
"semantic versioning" as a general concept, but I am aware that the
package repositories and the dependency format are just not prepared to
make use of it anyway.
Thanks for your help!