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#70036: a fix that Date: Thu, 18 Apr 2024 21:21:25 +0100 Message-ID: References: <86y19ad61t.fsf@gnu.org> <43de4151-ab68-4214-8691-33f3554feba1@email.android.com> <86r0f2d46x.fsf@gnu.org> <86jzkud0be.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="27617"; mail-complaints-to="usenet@ciao.gmane.io" Cc: felician.nemeth@gmail.com, 70036@debbugs.gnu.org, theo@thornhill.no To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 18 22:23:25 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 1rxYI1-0006yg-3c for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 18 Apr 2024 22:23:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxYHY-0004AQ-0U; Thu, 18 Apr 2024 16:22:56 -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 1rxYHR-00048o-Rj for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 16:22:50 -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 1rxYHR-0000gg-Jv for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 16:22:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rxYHe-0006EB-TC for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 16:23: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: Thu, 18 Apr 2024 20:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70036 X-GNU-PR-Package: emacs Original-Received: via spool by 70036-submit@debbugs.gnu.org id=B70036.171347172323524 (code B ref 70036); Thu, 18 Apr 2024 20:23:02 +0000 Original-Received: (at 70036) by debbugs.gnu.org; 18 Apr 2024 20:22:03 +0000 Original-Received: from localhost ([127.0.0.1]:54429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxYGe-00066r-7g for submit@debbugs.gnu.org; Thu, 18 Apr 2024 16:22:02 -0400 Original-Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]:46507) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxYGb-00065c-HP for 70036@debbugs.gnu.org; Thu, 18 Apr 2024 16:21:58 -0400 Original-Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-516db2214e6so1719774e87.1 for <70036@debbugs.gnu.org>; Thu, 18 Apr 2024 13:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713471698; x=1714076498; darn=debbugs.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=bSb1r13+rIbUFqbDfC7peYuBWJPojkWlb1/fSe1UqzQ=; b=jgGQszrAv/4Ubbcwy8gmibcXSBFCqJVxw5ipPA5PxAgvPRThmWAZi0WzMPeUUclw9l VTDRgRhdz3neaWbj9Kqj3TCjZc0R6GYG1Q4gg9jiOtxIYJAeYc2PaTD3iVPVEo4tuULe 3HtlrYIZUb7HI5AKqQhNwVxGmWGiNEer1Xnlcl7R/lTtzD7Qj9aUvm8Q2Rj8mwkzNrta nDERw2nr2GQ8f9kPzSMEw2VbDk4l7Y745OZecxTEQ1FKYXIak/sszJs95s5NftP5qSmK zmDd1yFi815hGx0cje8INPmlEBz/BaOnZO3CI74fYsADoH//U4U6cD4DtcLA/WrtsoxP +VYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713471698; x=1714076498; 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=bSb1r13+rIbUFqbDfC7peYuBWJPojkWlb1/fSe1UqzQ=; b=dXlQv1CAUAS+A7s3MuYO6qt+mEOhYZ4rwEnRj3rk+5t5Jy6EoMm3EjEc1xbgYUlc6b x/JhBAJOPWwF+sa3N/Lex0pZ0eiJjjWHUk2bpecIsT4qRD6IahP/8ebUatd0NsYBTU5x DTMNRrNZYQ8db8oCCtIsb+CLAFFJaRXM5eZtE9+2k2h2/KC+AP73PBbcraBxD2/YWd6B 2MRygThq8yKW4sP/q2EEVEM2Ts2Bu5JXnzwqy5UBHpQzCvftnA+Gyj7dFg7monwJ2b4W nfnbfQ75SBtv3z8ShrsZWvSFbf+vj4k3GGYrH1aQe767Q/sDiatxFhRx+emqyU8Ckykm ARzw== X-Forwarded-Encrypted: i=1; AJvYcCWKU9EoBiv4o4Ogrn8TSUa1qZdaysf99pd8FBvfXORHXXRyTbeMieZUYAcgbcmfDZAeDhCFwiXd618LDrpxpZhXIqefvXs= X-Gm-Message-State: AOJu0YxCSMdNnst4oh8gvG9XV8WKZxCs/ZY9WEpxJyMA6cB69rhsUMqh YrBwtuzj6pT9YFZHUFnv9emTlU63QLm6t4jNEH75vR0Nd5qAKxOTjHb2X46hino2CMBbTQ08Dgb nsamfebpXdSf9UqxBMcQOiLQAJPg= X-Google-Smtp-Source: AGHT+IHbUgt73TQ3LXj/jADwgRbU1gn7H1jisD7tDlkhgdPCUNXTLH0tCatw2f+86mOnB3k3SjwvJSaaPY1PFwc1yIg= X-Received: by 2002:ac2:5b8d:0:b0:516:c099:e798 with SMTP id o13-20020ac25b8d000000b00516c099e798mr59845lfn.31.1713471697480; Thu, 18 Apr 2024 13:21:37 -0700 (PDT) In-Reply-To: <86jzkud0be.fsf@gnu.org> 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:283613 Archived-At: On Thu, Apr 18, 2024 at 6:53=E2=80=AFPM Eli Zaretskii wrote: > I suggest to get an objective opinion of that from an uninvolved > party. I suggest you drop your sarcasm not because it hurts me or anything but just because you're not very good at it. > > So let's skip the morals. > > No, let's not. Really, you want to go at it again? Well let me just add a pinch of salt to your typical condescension lecture, getting some facts straight about what happened here. * I had to take a long timeout from Eglot maintenance for personal reasons managed to get maintainers for Flymake and Jsonrpc, but I am still Eglot maintainer. * I notice some discussions going on and I let them proceed with little input. * I regain some capacity some months later, notice a user report on GitHub alerts that there are some very new things in Eglot that didn't ask for explicit greenlighting as was usual during the last 7 years I'm maintaining Eglot. Fair enough, life went on without me. * I post to Emacs-devel about these. I take care to thank everyone for their efforts. * One of the changes is Stefan Monnier's. It's broken, he fixes it immediately in the usual good spirits. * Another one of the changes is Theodor's. It's a good change and I highlight it as such, merely request a change to the doc. * The other change is also Theodor's. I commend it for its clarity and implementation, but ultimately notice a serious bug that affects me and anyone else working a super-common C/C++ servers and symlinks. * I go and read the full bug report and notice that Theodor has been "studying Eglots performance" and has come to the conclusion that there is a hotspot of performance problems. He posts in that email what to this time is the only actual hard data we have. That data suggests that file-truename is slow, and that Eglot uses it a lot in eglot--TextDocumentIdentifier. It doesn't suggest anything other than it, nothing about textDocument/publishDiagnostics. There's 0 data about that and it never showed up in my profile. * Theodor suggests rewriting file-truneame in C, you decline or raise doubts. I don't follow the reasons, but fair enough, the discussion pivots to changing Eglot. * I reproduce Theodor's experimental findings. * I find a patch to address that hotspot that is several times faster than Theodor's solution (doesn't really matter though). * I ask Theodor to revert the patch and start afresh. He understands but declines. * I weigh the pros and cons, especially the time I have to address this and other Eglot recent problems (tests are borked, have to see what happene= d) Since I am Eglot maintainer and revert it myself, just like I've reverted my and others own perfectly well-intentioned and laboriously crafted commits many times and it hurts a bit to do it, but not that much= . It's a no-brainer to revert something like this to me. There is so far very little hard evidence of the effect this is having on the general population, it's a very uncommon report. This code has been there for 7 years and while there have been performance bugs, this was never one of it. This is why I write "one-off" and "uncommon". Absolutely accurate. Ultimately, I see that very little testing has been done around = some rather obvious use cases of removing symlink-smarts from Eglot. The "my servers happen not to have this" just isn't an acceptable argument to me. Sure if Eglot had behaved like this all along from the beginning, displayin= g duplicated references in some servers, maybe it would be different, but that's a different world. Bottom line, Eglot worked correctly three weeks ago and now has a new bug introduced by a performance fix based on very little hard data, and a single very scarse report. It's a no brainer to revert. Still, for the very little data that there is available, I do take care to put in a much simpler fix that completely fixes the issue - as far as I or anyone reading the available data can see it. Your last question to Theodor on this thread before the change was merge good but the answer was completely misinterpreted. You ask if the servers resolve symlinks and Theodor answers this: > The LSP specification does not talk about symlinks. The > servers I used let the operating system resolve symlinks for them. Well, maybe at that point if one would have noticed that there are hundreds of servers arounds, this could have taken a different turn. > > I've told you I'm invested in fixing Theo's performance problems, > > but I must learn more about them obviously. But I'm not going to > > keep a regression in just to be nice to people. > > If -- and it's stil an "if" -- it was a regression, Did you not read my experiment with the three-file project and the clangd server? https://lists.gnu.org/archive/html/emacs-devel/2024-04/msg00350.html Is anything unclear? If you've seen it but don't believe my results maybe you should try Eglot yourself: seeing is believing, they say. > it was there for quite some time So was the supposed relevant performance problem. Only that time is measured in years and this is measured in weeks. > , so nothing serious would have happened if we'd leave > it there for a few more hours or days. And nothing serious will happen after I reverted it, will there? I have no interest in delaying a responsible decision just for the sake of appeasing feelings that someone else says are there. If Theodor is worried about a specific performance problem I have some time this week and the next one to help fix it, and I'm confident I will. For the record my repositories at $DAYJOB with very long path names _and_ very symlinks. So I'm personally interested in fixing any performance problems and not opening new ones. > > I'm sure Theo can understand that. > > He obviously felt hurt, so "understand" is not an appropriate word > here. I'm confident he will understand this, I can't be sure of course. But I know he wrote "could absolutely do that [revert]" though he preferred not to do it. That at least shows that it's not an absurd proposition. And _I_ understand that he doesn't want to, of course. I don't know if Theodor felt hurt, and even if I suspected something, I wouldn't write about it in public simply because I personally find it in poor taste to speculate or moralize about others people's feelings secondhand. I await Theo's reproducible experiment so that we can work on what's really important. Jo=C3=A3o