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: Fri, 19 Apr 2024 09:01:25 +0100 Message-ID: References: <4e670617-6483-4159-a5cf-27a921764c38@email.android.com> <87wmot289d.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="23177"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 70036@debbugs.gnu.org, felician.nemeth@gmail.com To: Theodor Thornhill Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 19 10:03:20 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 1rxjDM-0005hm-R1 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Apr 2024 10:03:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxjCu-000259-2d; Fri, 19 Apr 2024 04:02:52 -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 1rxjCs-00024G-Gk for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 04:02: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 1rxjCs-0007BL-7e for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 04:02:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rxjD6-0004th-3b for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 04:03:04 -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: Fri, 19 Apr 2024 08:03:04 +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.171351372218217 (code B ref 70036); Fri, 19 Apr 2024 08:03:04 +0000 Original-Received: (at 70036) by debbugs.gnu.org; 19 Apr 2024 08:02:02 +0000 Original-Received: from localhost ([127.0.0.1]:57534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxjC6-0004jj-6F for submit@debbugs.gnu.org; Fri, 19 Apr 2024 04:02:02 -0400 Original-Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:59438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxjC3-0004hy-24 for 70036@debbugs.gnu.org; Fri, 19 Apr 2024 04:02:00 -0400 Original-Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-51acb95b892so146477e87.2 for <70036@debbugs.gnu.org>; Fri, 19 Apr 2024 01:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713513699; x=1714118499; 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=bKEYVZrIzc6RGHnW5bqODhNkm3v/gDkKcqRl3NGQgKo=; b=QkXBeH2vTC89F/E7sguUY1JqgcpBNBOUHvH/Ddq9A5lv6N1+f3L5zLvVievrU3pxbm OXGVtCdZYljgfk0HGIfWScpQk4AW/2O8S6fPWv7OpjRgJhhmJpCBgFVOaIkNs8qQZv0f u2ydrxSxOe8DfhmLgr9ny7qhHBOpYz9Up46SW5ZxOqkpE2rOJenGTZAyCrJnUTc/w91D S85WtvRJB/IpVNNhhFiLhJTRhMi1KwZtqP/uWwh/tpw7XHWAc5ZaquMjd+vxRxNegnqt 3Y0d3nCFWRyd985Fk1Ro6d5izjaoEmh9bZEu/IEQ0J2JZ9gzugvqWam+Y93oojDxfSXT 061Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713513699; x=1714118499; 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=bKEYVZrIzc6RGHnW5bqODhNkm3v/gDkKcqRl3NGQgKo=; b=vwIMjdVV4gRKRfPauoFhMW1rA1amuhAqdFbGv6fdtSvtBpEeDQnh4FsIcb/mLDOvp7 nustE5Z9+2HKmH28Ycl+HxTAIFrHYNvaqMRWWReuo2t2rHJfL4yP9rkaOKrg24lXi1ir 0gG8VWnXVNuhnVwRrpZoiLSFwcnur/QCFm8ZyoFA4ZbM6JYmwm+8WiEEi9SNbgrFdifK DoHypARMtHvqVqOE9qFV1lic/wRoHaAMEA/ulr4TI50bpVF9nsg9pdl8iOJvS36k6hpG hG8ubVVGF3pIlTH9+F8TRca2gI27ysW5GOvfwUj1douY/vfmblGUEKdBlinXprrw0dHg 1Uyw== X-Forwarded-Encrypted: i=1; AJvYcCUC3uuBrj/1Skr6Uk9Vp9RjIH/U1LnzC/PC6jW9zNd57f4jNtaNzFBNfysWTyJ17n9mcMmjt+W9lLA6Tc7GqEXcceiilkk= X-Gm-Message-State: AOJu0Yy55GExpPZNAaXNu/XOBpaTwJW62eOFkMSw+PHCq/MgLpGEq9v2 CRbXvxQhzSArKrKCR6cuFKF43Z6dlD29h5DWiJXrlY6ukmb79CRt6+pFzLYJi69N4LDapNKjMgH UbYXreX3Zi1qK1x5PYvWDCS8WTsY= X-Google-Smtp-Source: AGHT+IHxCgBn1Nf81bxqueslwDbniiI0rHGKlLzaphWUqOvkiUNVJDr+z42Hw07phT+s1TWCTDI/ILCENUpIIzgpz+s= X-Received: by 2002:ac2:4428:0:b0:519:5c34:9652 with SMTP id w8-20020ac24428000000b005195c349652mr1004732lfl.31.1713513698412; Fri, 19 Apr 2024 01:01:38 -0700 (PDT) In-Reply-To: <87wmot289d.fsf@thornhill.no> 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:283649 Archived-At: On Fri, Apr 19, 2024 at 7:09=E2=80=AFAM Theodor Thornhill wrote: > you've also noted earlier. I have an even stronger computer, a 2023 P1 > gen 5, I believe, running ubuntu. Some servers send _all_ diagnostics on > every keystroke. That could be, but what servers are these? Thought it would never be "on every keystroke" though. As you probably know, Eglot bunches them up in didChange notifications, and you can can even be the size of these bunches. > > So my perception is that it must have spent around 4% of 1 second in > > file-truename. > > > > Anyway the reason this shows in this profile is because this project > > with this particular server sends a lot of publishDiagnostics upfront. > > That's OK. Gopls is a very good server. I think I see a fix. But can > > you qualitatively describe the Eglot experience. Do you notice any > > input lag or something like that? With this project? I didn't feel _an= y_ > > lag. > > Super snappy. Maybe the JSON serde kicking in? > > > > In this particular project I don't notice any input lag. But on every > java project at work I absolutely do. But that could be down to other reasons Theodor. We would need data for that server too. Last time I tried jdtls (on a docker-based TRAMP setup, described somewhere in the mailing list), it was snappy. If you make a simple recipe like this one I can absolutely try though. The difficulty in that one was TRAMP. > > Anyway, the idea I suggested earlier is in the patch after my sig. > > > > Let's think: LSP's publishDiagnostics coming from the server deals > > in URIs, right? And we inform the LSP server about URIs, too, right? > > So the URI is always LSP's idea of the resource identifier (and it like= s > > to have truename URI). > > Sure, like in my key/value store. (apart from symlinking) The other difference is it uses buffer-local variables as the natural "per-buffer" storage method. > Could we rather use eglot--managed-buffers, like in my patch? there > shouldn't be a need to loop through say 200 buffers that are unrelated > to the project in question, right? Apart from this I agree, and will try > it. Of course, that's a good improvement. Jo=C3=A3o