From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Filippo Argiolas Newsgroups: gmane.emacs.bugs Subject: bug#64608: 29.0.90; Eglot: reuse server when visiting external files Date: Fri, 14 Jul 2023 15:55:50 +0200 Message-ID: References: <837cr24w1y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000039e4f8060072cfa7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="576"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 64608@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 14 16:16:16 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 1qKJag-000APL-Nk for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jul 2023 16:16:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKJaX-0001vu-A5; Fri, 14 Jul 2023 10:16:05 -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 1qKJaU-0001vl-Jq for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 10:16:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qKJaU-0000Jo-Ae for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 10:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKJaU-0002nE-63 for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 10:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Filippo Argiolas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jul 2023 14:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64608 X-GNU-PR-Package: emacs Original-Received: via spool by 64608-submit@debbugs.gnu.org id=B64608.168934415210712 (code B ref 64608); Fri, 14 Jul 2023 14:16:02 +0000 Original-Received: (at 64608) by debbugs.gnu.org; 14 Jul 2023 14:15:52 +0000 Original-Received: from localhost ([127.0.0.1]:43131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJaK-0002mh-6u for submit@debbugs.gnu.org; Fri, 14 Jul 2023 10:15:52 -0400 Original-Received: from mail-oa1-x2a.google.com ([2001:4860:4864:20::2a]:52640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJHF-00023H-1O for 64608@debbugs.gnu.org; Fri, 14 Jul 2023 09:56:09 -0400 Original-Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-1b0719dd966so1536431fac.1 for <64608@debbugs.gnu.org>; Fri, 14 Jul 2023 06:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689342963; x=1691934963; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/ztRj8Le9ZTFkqOeQIEsxzysnasXsMF+rZHUpHMI454=; b=kntgYkWZf1750Aep0ST8mdIbAokkiNefUgeYTM2ElATj0DY9FVm6kX4mmhD9QyKv64 11LD3V8Fxb2lHHzj9p+mwDLwwJ987P5IMjdjuxkonvx0itAOD2bwCQ+FwTJE62yx2CqJ S3YFuKd9q72d20s5RYhPmNiqsls2HzDJfOeY2L0ysGlzaVVpJBRSHvMJet/ZnX2X6tB1 dQAtl2E7na8TvK+rl7PVPRP3yzUxzDITWZEAYcJFKPXPs2vit4MCg0AT5s8pWsj+5pgz P9T6Ze8+02cLnlEpMh8ct7iI9wc26/mOuH/fa15q0yOwXFwxozdoC4i1ACY2ls9IEDvb xVOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689342963; x=1691934963; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/ztRj8Le9ZTFkqOeQIEsxzysnasXsMF+rZHUpHMI454=; b=A2J2j7M75N+b9gNIw+/isQJ1N1Nn0D9Pb4dA7+YgZezIIc0lKrkTEyMgD6rKqWlmp/ pvBe63yDRWpsuPNFQ5yp8iqw4aKOhr2sdDIgjGYtj5AWCavg5ivFXxVRFP/+BfZRyH0L PSpnS+wp7YbPW6PO/+ZNzTZYsd5Mhfy49YxUhH3ZFFFnbxDZEIAStGGYjvXp4cjqgj3y Jqgiax05kn4ATQ4T1N2DwcauWE7KSdfHGnk9ep1gQH/fz/U3/vWhVSbGMWMO2fqR39dW g8fat+fOumnbzmG+vHxkT0iXrjR2owxn1GSUYhFpSbY2jDS+M9izuyVnTjwkRrEm7+3V zfrw== X-Gm-Message-State: ABy/qLYAAdCe9xRJcasBLZRrwlohj0nZW4UsgcLrpy1I5HIpobw7FgMn jFCAq7WkyeYO7sU34cL1Wwwyz52JynlFVWPqtHY= X-Google-Smtp-Source: APBJJlGD2EYOxhVLvsviYXkkV1DFOymWHx3hTL4TAInbq6MYRm2QbAbEiOl0p6QiKG6aDfsdvyHKGnoiYr2iOF2NIqg= X-Received: by 2002:a05:6870:c115:b0:1b3:e896:9bfa with SMTP id f21-20020a056870c11500b001b3e8969bfamr6006105oad.25.1689342963211; Fri, 14 Jul 2023 06:56:03 -0700 (PDT) In-Reply-To: <837cr24w1y.fsf@gnu.org> X-Mailman-Approved-At: Fri, 14 Jul 2023 10:15:51 -0400 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:265095 Archived-At: --00000000000039e4f8060072cfa7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Il ven 14 lug 2023, 12:38 Eli Zaretskii ha scritto: > > From: Filippo Argiolas > > Date: Fri, 14 Jul 2023 07:51:28 +0200 > > > > Hi, > > > > I'm working on a couple of projects each with their main root and all > > sharing some common code in an external root dir. > > > > Each project has a compile_commands.json that knows how to compile the > > external shared code. External root has no compile db and doesn't know > > how to compile itself. > > > > Eglot currently allows me to jump to external files using xref while > > keeping the current active running server by setting > > eglot-extend-to-xref. > > > > Project.el allows me to visit external files using project-or-external- > > functions by defining project-external-roots on my custom backend or > > project-vc-external-roots-functions with the default backend. > > > > It would be great if I configure Eglot to not switch to a new server > > when visiting an external file in a similar way it does with xref. > > > > Any pointer to achieve something like this with current project.el and > > eglot code would also be great. Maybe with a custom project backend? > > Sorry, I don't understand: AFAIU Eglot reuses the same server for all > the buffers under the same major-mode, so you should already have what > you want? Or what am I missing? > > Adding Jo=C3=A3o to this discussion. > I could be misusing the word server here, what I'm seeing is a clangd instance for each project. Each with its own hidden stdout/stderr buffer. Not sure if they're actually different processes, far from the laptop at the moment and cannot check, but I guess so. When I visit a file in a new project it starts a new clangd instance associated to its root dir and its compile db if it exists. All buffers from the same project share the same instance. Not sure what happens with different major modes as I'm using c-mode only. What I'd like is to reuse the same instance and the same compile db if I'm visiting an external file from project-or-external- functions. Filippo --00000000000039e4f8060072cfa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Il ven 14 lug 2023, 12:38 Eli Zaretskii <eliz@gnu.org> ha scritto:
> From: Filippo Argiolas <filippo.argiolas@gmai= l.com>
> Date: Fri, 14 Jul 2023 07:51:28 +0200
>
> Hi,
>
> I'm working on a couple of projects each with their main root and = all
> sharing some common code in an external root dir.
>
> Each project has a compile_commands.json that knows how to compile the=
> external shared code. External root has no compile db and doesn't = know
> how to compile itself.
>
> Eglot currently allows me to jump to external files using xref while > keeping the current active running server by setting
> eglot-extend-to-xref.
>
> Project.el allows me to visit external files using project-or-external= -
> functions by defining project-external-roots on my custom backend or > project-vc-external-roots-functions with the default backend.
>
> It would be great if I configure Eglot to not switch to a new server > when visiting an external file in a similar way it does with xref.
>
> Any pointer to achieve something like this with current project.el and=
> eglot code would also be great. Maybe with a custom project backend?
Sorry, I don't understand: AFAIU Eglot reuses the same server for all the buffers under the same major-mode, so you should already have what
you want?=C2=A0 Or what am I missing?

Adding Jo=C3=A3o to this discussion.

I could be misusing the word server h= ere, what I'm seeing is a clangd instance for each project. Each with i= ts own hidden stdout/stderr buffer. Not sure if they're actually differ= ent processes, far from the laptop at the moment and cannot check, but I gu= ess so.

When I visit a f= ile in a new project it starts a new clangd instance associated to its root= dir and its compile db if it exists. All buffers from the same project sha= re the same instance. Not sure what happens with different major modes as I= 'm using c-mode only.

What I'd like is to reuse the same instance and the same compile db i= f I'm visiting an external file from project-or-external- functions.

Filippo




--00000000000039e4f8060072cfa7--