From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#70408: 30.0.50; Eglot and Project integration Date: Sat, 20 Apr 2024 14:28:26 +0300 Message-ID: <51785013-d847-4a1d-a5df-3b25dcf1084c@gutov.dev> References: <87o7aas3sk.fsf.ref@aol.com> <87o7aas3sk.fsf@aol.com> <86le5djzz2.fsf@gnu.org> <8cfba95b-fedd-4b5f-9778-d656601006d1@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37612"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Eli Zaretskii , 70408@debbugs.gnu.org, Ergus To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 20 13:29:11 2024 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 1ry8u6-0009XE-Tt for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 20 Apr 2024 13:29:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ry8tq-0001TI-5O; Sat, 20 Apr 2024 07:28:54 -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 1ry8tm-0001Si-IS for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2024 07:28:51 -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 1ry8tm-0003TH-9l for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2024 07:28:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ry8u0-0002qY-Bq for bug-gnu-emacs@gnu.org; Sat, 20 Apr 2024 07:29:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Apr 2024 11:29:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70408 X-GNU-PR-Package: emacs Original-Received: via spool by 70408-submit@debbugs.gnu.org id=B70408.171361253810870 (code B ref 70408); Sat, 20 Apr 2024 11:29:04 +0000 Original-Received: (at 70408) by debbugs.gnu.org; 20 Apr 2024 11:28:58 +0000 Original-Received: from localhost ([127.0.0.1]:35855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ry8tr-0002os-R8 for submit@debbugs.gnu.org; Sat, 20 Apr 2024 07:28:57 -0400 Original-Received: from fout4-smtp.messagingengine.com ([103.168.172.147]:45269) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ry8tn-0002ni-Mz for 70408@debbugs.gnu.org; Sat, 20 Apr 2024 07:28:53 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id AF0271380DE5; Sat, 20 Apr 2024 07:28:31 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 20 Apr 2024 07:28:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1713612511; x=1713698911; bh=HKFXvEjHkdlefXHhjGCqLl2VNgtGK5qE1y8jdabrlPc=; b= x8As1xKHB0b1fhH2r5IObzuqslKuOmfDsWGCnNOgi047BhhC+b7rLDPCt+mgX99s gWAJaw2kiQ4BkPr5tE8KWBOp5/7SJ6hBK4A2pag2pzxuseZFm8BAWjlZ42OSEmsu qoCLcgjtog2zeRSmlCxksr1Vt+KQeqQX72IsF6lnpXc9ypIsCfx1ffxgo8+rshZq mZ1ZZ5ezZpiyl3+w2kNaX4TRzTVH7n1r7FVJYpZP0uE+N01QIt/CKRnGOUmKQmTc rYoz8/jcgUR0eG5yHEZXGPeSh6/RdDwVkpFDwMGwB2XPzDfDuTKT+dyz9DcCh8Mu vm0AGs+s85fC5E7+5EEM9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1713612511; x= 1713698911; bh=HKFXvEjHkdlefXHhjGCqLl2VNgtGK5qE1y8jdabrlPc=; b=M B4II8RFZAuV9Daein0OEaiWV6xcaotK8ZkMJSOYx5pfzQ/Df3l1Pf+JbMhL1EJX0 +JPaAyqz7xDa29TgqK2BpcIvSM3HX9zoAd8w+weoU1+4tFLkY5h9j5Y/lSOVvJfP L9lro7RJStRyp3CeMfS+PhXEyL5mUQWBF79FramE6Z15I7dW+xyvaugEb4z8ccHu VEQSb3Q2fcB7WiOn+vciXFEzEidId6nezOAXrjdFH0mB70orvpbD22nu+1tu5Ikd O+XvF4/WGY0PAMewN9OAjpvPWcayJt3HDz2b9guXQjjFpGPf4tAX3Ai0Qm3Ki42o KffsZ8x2K5LBtWKYnD5MQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudekgedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepueetudfhiedtjeekuefffeehgfffveevteejtdfhteetgeethfevueejkeej gfevnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 20 Apr 2024 07:28:30 -0400 (EDT) Content-Language: en-US In-Reply-To: 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:283732 Archived-At: On 16/04/2024 16:51, João Távora wrote: > On Tue, Apr 16, 2024 at 1:56 PM Dmitry Gutov wrote: > >> IIUC Ergus's request is primarily about a situation where an >> "out-of-tree" build is used. Meaning, the directory for build artefacts >> is not a subdirectory of the project root, but -- apparently -- some >> sibling directory of it (e.g. "../build"). So it's somewhat atypical, >> although I suppose the solution from the link above might work with it too. > > Ah, I know about that. That's where compile-commands.json is generated > by CMake. But using that './build' as the project root passed via LSP > to clangd > (and likely any other server) will most likely fail: that's not the > project root > and it doesn't have any versioned source files (only auto-generated ones). > > Because of this, C++ projects usually have sth like: > > ln -sf build/compile_commands.json compile_commands.json > > as a build step. Would you say it's common across most projects? E.g. generated as a build step by CMake in out-of-tree comfigurations. Or is it something Emacs users tend to add. What I'm wondering is whether we might be currently disadvantaged compared to the users of some other editors, which might have some more auto-detection in that area. > Alternatively, you invoke clangd with `--compile-commands-dir=build`. > I don't think there's anything project.el or Eglot can do or should do > about this case. > >> This bug is split off from an emacs-devel discussion, where I posted a >> draft solution of mine: >> https://lists.gnu.org/archive/html/emacs-devel/2024-04/msg00279.html >> I'm curious for any feedback - like would that be good enough for this >> and related cases, or maybe if someone has an even simpler approach in mind. > > I'll pass, but wish you luck. I've stated in the past that I think > project.el should > allow subprojects inside larger projects, and let users of > project-current (direct > or indirect) specify if they're interesting in the innermost, > outermost, or intermediate > projects when searching for projects to act on, via a combination of prefix > arguments, arguments, customized special variables or let-bound special > variables. I'm open to continuing this discussion somewhere, but it's unrelated to this particular one. Note that, as I explained, it would be easy to create a set of commands acting on "super" projects, but that's probably not what you're looking for.