From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: master 08c80c45dde: Don't use file-truepath in Eglot (bug#70036) Date: Thu, 18 Apr 2024 01:24:59 +0100 Message-ID: References: <171215083924.12380.5369373861551158668@vcs2.savannah.gnu.org> <20240403132719.A18EFC12C28@vcs2.savannah.gnu.org> <87il0fsufu.fsf@thornhill.no> 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="25195"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Theodor Thornhill Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 18 02:26:11 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 1rxFbP-0006KD-MR for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Apr 2024 02:26:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxFaZ-00009Q-A7; Wed, 17 Apr 2024 20:25:19 -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 1rxFaV-000097-Ai for emacs-devel@gnu.org; Wed, 17 Apr 2024 20:25:15 -0400 Original-Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rxFaT-0001ax-EF for emacs-devel@gnu.org; Wed, 17 Apr 2024 20:25:15 -0400 Original-Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2d8863d8a6eso4627311fa.3 for ; Wed, 17 Apr 2024 17:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713399911; x=1714004711; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nnP0QWTVL/Ud1TamnRpDuK7WYy3XLY8iujgQNGhqzpI=; b=HfZcfchADc1uUEDfnltvZLHbfkpfB1xSH5TZd6gMMU8uJE0tawRWvZ9AJG6On5dqn0 prapsu4j7W46yP5M0DX1BB3J91pjZ/RaqJRUMb3H7Sqhrj3594c/cyeksqDHSLl/mwAv FDq6J95dc7oiSHew95Am6XeTJ650siEGgJQ6cZVxAyJ4SoOt6TpOfegzuAUpjN5DAMMN Yd33jpiiot09vkjsXhcXI/yVR5CDZAbVz71EJeg9a3ixtdlb8OJBVNk2S9iqAXpawNB+ byX6RgdHwkxcQfsl1kWVuvVAmjjrdtDemRnUCjdMmbIb8JtwOkDYc8d+zHWzFaUpB7V5 b+vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713399911; x=1714004711; h=content-transfer-encoding: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=nnP0QWTVL/Ud1TamnRpDuK7WYy3XLY8iujgQNGhqzpI=; b=KYPWFGXjeoRqTjRmyl8W92x+lvOSiFyYGOXsYT5GhTJRGGn9ycmb+UQOHI4Ac3WtY6 I7OzXq0tsNfdVgd7tKuufVE5wyRPhQCzokFvav90yOsiKrBcewEJUDb3tbtb3GY0dblj GjgRUBUdyKOp+loyAXmTJrU5OWI5csUOaB9K2NYo5SSOFYvhbSncMhe/8wqGfbmfoPms qwdX8Fg34h8n+WDJKOg7Qs8iiQwwZ0GS+1WIdCW0VLd7y5NMJ4UED/xFHXj9nFH8tSfz +BOcT4Zwp5EkXwfM4+1Oy3QaETgTQtXAGFcihLpehsthfmf6e5HVUOX1N5Ps8v8ACH83 ItXw== X-Gm-Message-State: AOJu0Ywwl9/pY8lul/kAXiGBe29mdT/AnZYXyHZDzfeJS306211kc6Or +w8LnCSjxUyjHfVbcWOsEYdtowc+Xizz9s8gN/+dzesyTqWRUfo+S/xPoLerluQR5Hr/tcBRnlK vxcTT/A6WW14LQ0pQvHFD8u7sgmGQGM5L X-Google-Smtp-Source: AGHT+IHLSWh23Goku8Nibn2soH4iPhZ4Iv3xNW+8UL/5mQsPLmcNRCHZSMlN+HwA3ltkdcUS1UmWl16n7jTxvq3IfOY= X-Received: by 2002:a05:651c:221a:b0:2d8:49e2:d279 with SMTP id y26-20020a05651c221a00b002d849e2d279mr690823ljq.26.1713399911034; Wed, 17 Apr 2024 17:25:11 -0700 (PDT) In-Reply-To: <87il0fsufu.fsf@thornhill.no> Received-SPF: pass client-ip=2a00:1450:4864:20::234; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x234.google.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:317789 Archived-At: On Wed, Apr 17, 2024 at 7:41=E2=80=AFPM Theodor Thornhill wrote: have been looking for an Eglot maintainer but everyone I contacted > If you want I can do this - so that you don't have to. I've been > considering it for some time after I responded to your call for > maintainers. OK, I've added you to the GitHub repo as a collaborator. Let me know off-list what your intentions are (to phase it out, keep it and take it over, or whatever) and let's see how it goes. > > The change seems well structured, well coded, and well described in the > > commit message, so I could understand it easily. Do keep that up. > > > > But of course going from file-buffer-visiting to something else > > whose underlying implementation is faster but doesn't chase > > symlinks is probably going to have some kind of functional implication > > right? I wonder if (or rather "I hope that") you guys considered it. > > I did - and afaict it has no such implications. It I've identified at least one implication. A rather obvious one, given that you've effectively removed symlink-awareness from Eglot. When working in a project with symlinks and visiting such symlinks, the LSP server is now informed (via LSP 'didOpen') of the symlinked file as if it was its own file, whereas before your changes Eglot sent over the true name of the file. You can see this easily from M-x eglot-events-buffer. What does this mean in practice? Many things potentially, but at least this one: I've run this experiment: In a new dir, create a lib.h file with this silly content: int foo(); Then create a main.cpp like this: #include "lib.h" int main() { return foo(); } Then create a mainlink.cpp symbolic link to main.cpp Then M-x eglot (launches clangd server to manage the new directory as a project). 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. Before you change, Eglot will -- correctly -- tell me there is a single user of lib.h's foo() function in my project. After your change, it tells me there are two users. This is wrong, there is only one. It could be that some servers with direct access to the file system can deduplicate the information and add back the symlink smarts. But clangd doesn't do this, and in general servers _can't_ do this because LSP models a virtual file system. 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. So this seems like a pretty big flaw to me after just minimal surface scratching. Please reinstate the previous code. We can resume discussion of your performance problems in the bug report. I've seen the profile reports and file-truename is not thaat big of a problem. But nevertheless I think I can help you think of other places to cache things. Caching eglot--TextDocumentIdentifier per-buffer seems like a much easier way to solve your problems. Jo=C3=A3o