GNU bug report logs - #42765
26.3; project-find-regexp broken in Emacs 26.3

Previous Next

Package: emacs;

Reported by: philipk <at> posteo.net (Philip K.)

Date: Sat, 8 Aug 2020 16:43:02 UTC

Severity: normal

Found in version 26.3

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 42765 <at> debbugs.gnu.org, "Philip K." <philipk <at> posteo.net>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#42765: 26.3; project-find-regexp broken in Emacs 26.3
Date: Mon, 10 Aug 2020 18:58:50 +0100
[Message part 1 (text/plain, inline)]
On Mon, Aug 10, 2020 at 2:17 AM Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>
> Hi Philip!
>
> On 08.08.2020 19:42, Philip K. wrote:
>
> > after loading project.el into Emacs 26.3, I noticed that
> > project-find-regexp doesn't work, because the xref--show-xrefs function
> > has changed it's parameter interpretation. While project.el assumes it
> > accepts a function, 26.3's Xref assumes it will recieve a list
> > ("xrefs"). There command then fails with a somewhat cryptic error
> > message, that probably doesn't make sense for Elisp programmers.
>
> Thank you very much for testing this.
>
> > I managed to fix this by installing a newer Xref version from ELPA, but
> > I think this situation should be handled more gracefully. Is there a
> > reason that project.el doesn't depend on the newer Xref version?
>
> Unfortunately, that would make project.el and xref recursively depend on
> each other. And apparently that would be a problem:
> https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01615.html
>
> I'm not sure what's the best way to fix this.

Cyclic dependencies are bad in any packaging system. If two packages
depend on each other as a cycle, they are for packaging purposes "the same
package".  So Stefan's suggestion to make a multi-file-package seems
sensible.

The other common way to solve this is to split one of the packages, breaking
the cycle.  Or maybe creating a third "interface" package and adding an
indirection
(not sure if that's what Philip is suggesting).

So there seem to be escape hatches here, the best one is found by looking
exactly at what breaks, what are the external interfaces of each package,
why
and where they _need_ to depend on each other. I'm afraid I don't have time
to do this right  now.

João
[Message part 2 (text/html, inline)]

This bug report was last modified 4 years and 233 days ago.

Previous Next


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