From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#42765: 26.3; project-find-regexp broken in Emacs 26.3 Date: Mon, 10 Aug 2020 18:58:50 +0100 Message-ID: References: <87tuxd5bsw.fsf@posteo.net> <881b1e98-87b6-92b2-5ab3-d0297ce92555@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a6940605ac89b558" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27356"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 42765@debbugs.gnu.org, "Philip K." , Stefan Monnier To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 10 20:23:51 2020 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 1k5CSd-00071R-4b for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Aug 2020 20:23:51 +0200 Original-Received: from localhost ([::1]:41502 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k5CSc-0005Ll-7J for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Aug 2020 14:23:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k5C5a-0004dY-Pm for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2020 14:00:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54158) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k5C5a-0000Ud-D9 for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2020 14:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k5C5a-0004ME-7B for bug-gnu-emacs@gnu.org; Mon, 10 Aug 2020 14:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Aug 2020 18:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42765 X-GNU-PR-Package: emacs Original-Received: via spool by 42765-submit@debbugs.gnu.org id=B42765.159708234916660 (code B ref 42765); Mon, 10 Aug 2020 18:00:02 +0000 Original-Received: (at 42765) by debbugs.gnu.org; 10 Aug 2020 17:59:09 +0000 Original-Received: from localhost ([127.0.0.1]:37471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k5C4j-0004Ke-7V for submit@debbugs.gnu.org; Mon, 10 Aug 2020 13:59:09 -0400 Original-Received: from mail-wr1-f42.google.com ([209.85.221.42]:37311) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k5C4h-0004KR-KV for 42765@debbugs.gnu.org; Mon, 10 Aug 2020 13:59:08 -0400 Original-Received: by mail-wr1-f42.google.com with SMTP id y3so9028409wrl.4 for <42765@debbugs.gnu.org>; Mon, 10 Aug 2020 10:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VFNwbBIhYHH/6dNGSoE9l9fOyZ/VznzREXDxK+iAYuM=; b=VDEkjllpuJ5EUWSK4toPOBDjN7JQtEhWzQQORpkexlxvF2+1cp8dYwVUAJfHIqYp7t t4VbK8wrZDi0/sqnCc0tII3JXxAseS77q79kKyAhYfMDe1TApBSP1xA6vjQbm3A4j9wk GpM87+x36jOKUk8y2iJ/2YScXBqScZBkCxDsd91BqYOV9jTWl+RdMyxvywl2YaxZ+48s ku6NhYk47RXiE/yIdzh8so+KUAokFnRATdN4arIu8lqFz+N8cbpr7QbNg5bb7UxEU18v reG+ot0XCOOpQj5cYs7LL3u1BIJuoWJ8NghtGw7LGuWu5Tsca6w/99JDudRUgITFsQQ6 thNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VFNwbBIhYHH/6dNGSoE9l9fOyZ/VznzREXDxK+iAYuM=; b=iWFvYgO0ONui1WWiFWJ/1SHtC3nNem1n750XFKzzLp5bYIxp5/U84NE+bxbE69R0QH BIUtbsPmDwD/WBsBZR7cYgXGO/Aa+AtYXSaKghTUGuaKQOdS81t+bnExAR6BmdzRNUuG xpHqUXGaQs8aC9IOHJ+30aXGP9OmaHtvPn/W0nARLBLPwgNxtuL+/8knrw4BxSL2KPsk jogVJ5N8YjbGF1FHaRBppWqYOYYImnQJlt9VdV9/Rjn4kukxxjZnlrXMPhMGuqZgNhua ytwBgZKjGl9mvd0zsxkGWLONEI4sWJfFASYapX8FxOFXQCn1/PpEPOyyiUUweMt6lS5m JGRw== X-Gm-Message-State: AOAM531wKLUYCQD+SPg8SRND+9czQi8FZHGIbSLQKU2SIdAZrfY3eeML QbpS90kdZxRHN+2B/tQgpR6sW4CpK8hTzapwWSg= X-Google-Smtp-Source: ABdhPJyr7vQvZ9bgu9/tae6kg+18OrLq/nMuMcsBwzbLaxBRixPmndELB7juUXiH6TN9ezZwGDRrPgyw8u50zfC8in4= X-Received: by 2002:a05:6000:18a:: with SMTP id p10mr23813728wrx.33.1597082341642; Mon, 10 Aug 2020 10:59:01 -0700 (PDT) In-Reply-To: <881b1e98-87b6-92b2-5ab3-d0297ce92555@yandex.ru> 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" Xref: news.gmane.io gmane.emacs.bugs:184572 Archived-At: --000000000000a6940605ac89b558 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2020 at 2:17 AM Dmitry Gutov 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, breakin= g 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=C3=A3o --000000000000a6940605ac89b558 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 10, 2020 at 2:17 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
>= ; Hi Philip!
>
> On 08.08.2020 19:42, Philip K. wrote:
><= br>> > after loading project.el into Emacs 26.3, I noticed that
&g= t; > 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 assu= mes it will recieve a list
> > ("xrefs"). There command = then fails with a somewhat cryptic error
> > message, that probabl= y doesn't make sense for Elisp programmers.
>
> Thank you v= ery much for testing this.
>
> > I managed to fix this by in= stalling a newer Xref version from ELPA, but
> > I think this situ= ation should be handled more gracefully. Is there a
> > reason tha= t 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:
> h= ttps://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01615.html
=
>
> I'm not sure what's the best way to fix th= is.

Cyclic dependencies are bad in any packaging system. If two pa= ckages
depend on each other as a cycle, they are for packaging purp= oses "the same
package".=C2=A0 So Stefan's sug= gestion 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.=C2=A0 Or maybe creating a third "interfa= ce" package and adding an indirection
(not sure if that= 's what Philip is suggesting).

So there seem t= o be escape hatches here, the best one is found by looking
e= xactly at what breaks, what are the external interfaces of each package, wh= y
and where they _need_ to depend on each other. I'm afraid I= don't have time
to do this right=C2=A0 now.
<= br>
Jo=C3=A3o

--000000000000a6940605ac89b558--