From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill Newsgroups: gmane.emacs.devel Subject: Re: master 08c80c45dde: Don't use file-truepath in Eglot (bug#70036) Date: Thu, 18 Apr 2024 08:16:18 +0200 Message-ID: <87bk67rya5.fsf@thornhill.no> References: <171215083924.12380.5369373861551158668@vcs2.savannah.gnu.org> <20240403132719.A18EFC12C28@vcs2.savannah.gnu.org> <87il0fsufu.fsf@thornhill.no> <86o7a7fcf4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39974"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii , =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 18 08:17:14 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rxL56-000A6X-8Q for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Apr 2024 08:17:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxL4O-0002oK-TE; Thu, 18 Apr 2024 02:16:28 -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 1rxL4N-0002nx-SH for emacs-devel@gnu.org; Thu, 18 Apr 2024 02:16:28 -0400 Original-Received: from out-189.mta1.migadu.com ([95.215.58.189]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rxL4L-0000zz-8w for emacs-devel@gnu.org; Thu, 18 Apr 2024 02:16:27 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1713420982; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DnlVohWsZk0vU3ERRTzH8NW6sty7jxPex6oP/D776Qk=; b=O1zZ/5S2Dab5ejFmNDNeYKQ3FNu9H3N29YRFWk+JuKXHiEymnVgSzaCX5ZQ22cBOL45OLP pbY/0mxtuw0EDnbgD1qGpTe/e4IQoLmfqMYez6jdX1/7tZROnGrV58MiX73P2QDOG5XFcU JCGZ1P+vgtIUkWydaVUkjY5v45lpYL57BTNpBQgAYjFSvpSxnOgfeOnACGciXDO5ovuHNo 5Mf9WASyGZrYwKtcT9i8fb9yVA8E4sLwd/r2AVPgC+Bn0aWippxZSAq1govfGSxDWP7QuQ aNlG/BFUx7E5eNr7ewIJjLTcA5eCLj8CCFPSI377D/V24k5KpqZlvxHKOYmEGg== In-Reply-To: <86o7a7fcf4.fsf@gnu.org> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=95.215.58.189; envelope-from=theo@thornhill.no; helo=out-189.mta1.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317799 Archived-At: Eli Zaretskii writes: >> From: Jo=C3=A3o T=C3=A1vora >> Date: Thu, 18 Apr 2024 01:24:59 +0100 >> Cc: emacs-devel@gnu.org >>=20 >> Let's say that during the Eglot session I visit both main.cpp >> and mainlink.cpp in different buffers (either because I don't visit >> them at the same time or because find-file-existing-other-name is >> nil). Then I press M-? on lib.h's foo() to tell me who references it. >>=20 >> Before you change, Eglot will -- correctly -- tell me there is a single >> user of lib.h's foo() function in my project. >>=20 >> After your change, it tells me there are two users. This is wrong, >> there is only one. >>=20 >> It could be that some servers with direct access to the file system >> can deduplicate the information and add back the symlink smarts. >>=20 >> But clangd doesn't do this, and in general servers _can't_ do >> this because LSP models a virtual file system. >>=20 >> And for symlinks to large enough files, I'd be surprised if this >> doesn't slow down the performance of the server because it has to >> analyse what it is told is a completely new file. >>=20 >> So this seems like a pretty big flaw to me after just minimal >> surface scratching. Please reinstate the previous code. > > I asked exactly this question when the change was discussed, and was > told that symlinks are not a problem. > I still believe it is not. The spec [1] states the URI should follow rfc3986 [2], which states that ``` Because URIs exist to identify resources, presumably they should be considered equivalent when they identify the same resource. However, this definition of equivalence is not of much practical use, as there is no way for an implementation to compare two resources unless it has full knowledge or control of them. For this reason, determination of equivalence or difference of URIs is based on string comparison, perhaps augmented by reference to additional rules provided by URI scheme definitions. We use the terms "different" and "equivalent" to describe the possible outcomes of such comparisons, but there are many application-dependent versions of equivalence. ``` This to me reads that we shouldn't really consider symlinks, and if necessary it should be done on the server side.=20 I tried the exact same recipe Joao provided in java and go. It works in java, but not go, and that is mentioned here [3] > If we need to support symlinks in Emacs instead of leaving this to the > LSP servers, we could perhaps do that once in some strategic place, > instead of using file-truename everywhere where normally > expand-file-name would do. Or maybe explicitly test with > file-symlink-p before using file-truename, which is (and has to be) > pretty expensive. IOW, "punishing" everyone for the benefit of > relatively rare use cases is not the best optimization I agree with this. I'll test it a little. Theo [1]: https://microsoft.github.io/language-server-protocol/specifications/ls= p/3.17/specification/#uri [2]: https://datatracker.ietf.org/doc/html/rfc3986 [3]: https://go-review.googlesource.com/c/tools/+/454355