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#61726: [PATCH] Eglot: Support positionEncoding capability Date: Fri, 24 Feb 2023 11:18:11 +0000 Message-ID: References: <87a614g628.fsf@gmail.com> <83cz60r7hu.fsf@gnu.org> <875ybsfvtj.fsf@gmail.com> <831qmgr17p.fsf@gnu.org> <87wn48ecdz.fsf@gmail.com> <83v8jspgnr.fsf@gnu.org> <87lekodxja.fsf@gmail.com> <83a614p4sh.fsf@gnu.org> <87cz60dus9.fsf@gmail.com> <835ybrpnqj.fsf@gnu.org> <87y1oncz09.fsf@gmail.com> <83r0ufo3uc.fsf@gnu.org> <87356vbf0b.fsf@gmail.com> <87wn479vj7.fsf@gmail.com> 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="29039"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61726@debbugs.gnu.org, Eli Zaretskii To: Augusto Stoffel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 24 12:17:14 2023 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 1pVW4g-0007In-Gz for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Feb 2023 12:17:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVW4c-0005Pf-43; Fri, 24 Feb 2023 06:17:10 -0500 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 1pVW4U-0005PE-UO for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 06:17:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVW4U-0005dN-M9 for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 06:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pVW4U-0005hR-Eh for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 06:17:02 -0500 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, 24 Feb 2023 11:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61726 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 61726-submit@debbugs.gnu.org id=B61726.167723739521869 (code B ref 61726); Fri, 24 Feb 2023 11:17:02 +0000 Original-Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 11:16:35 +0000 Original-Received: from localhost ([127.0.0.1]:36067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVW43-0005gf-FP for submit@debbugs.gnu.org; Fri, 24 Feb 2023 06:16:35 -0500 Original-Received: from mail-oa1-f47.google.com ([209.85.160.47]:38884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVW42-0005gT-BP for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 06:16:34 -0500 Original-Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-1720433ba75so19332726fac.5 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 03:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677237388; 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=rT/Wlc4WtcVENfqZPVcOlpTAHJVUmy5mq6iUJ5+fcD8=; b=cH4BhOOU2jtq+Iw6Sjze25w4ZFdte2KyeXhO6ZR2XO4eToZrVFR8+nAgGqSbgCZD8A O1x0SR4p4t5nJJolZXNnThjkzxdUmI3cx6dhMYAdQspO5w1hkJ0Yq/5dZhB1+fs3YS0l 9cUK6xHS8KaYbQuEojryodc27Flir9IZnVYTo26v3JionGoW5nn22DfTwicyFuJI3ZwM AaVZxQ4peu2TotV69i/ahQJr/R3lUjH6civ258OrVOeRSZgLheln30gYuEa8M3GfSVT3 6yqMzoaVZT3tVjYjxmYVE7s98vj8bLm558iZ8wRXC63L6SoYkUmV1UDccnFF7goJuL6A 7ZBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677237388; 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=rT/Wlc4WtcVENfqZPVcOlpTAHJVUmy5mq6iUJ5+fcD8=; b=RZGEKtlsOE95a9+p+Ui7jTJjiIijjmJbTlqPXhwB1CdQ76tpiYT7ZZMo9VYOVXYCw5 jgPlRCS+o1GObnu6SjaMpGBLqISPoDUY3qa+5r1mYppureY20p9DCtJL2tiBRJ34PFzS b2tgZKgyyhUuM9mWAL7W8GlZcHaD+ahBs0cGUhgvKWe1DnpBj+FFKgfwNLLASxPYOmAh fKhhmaBFQeYatP/UGuU6VvmhL/ufDjs7u3zaymTpqsTbe3M+8vrXhLuM1zux/sm537qL XenAOJ99V2ccHNbiHXzvtJZFZ4QHU8zLrFyKlBSgUqwGdqb7fGldMfWNcGW37ZSMuZOg HBBg== X-Gm-Message-State: AO0yUKWlLIW2H0zE5Npzdj5LrfRk/CWXX1JwvUn//GQ5M4U9nXvaj7Mi DaXPUL900eEwNTn9w/qelj6eoh1J49i6xgfEqS4= X-Google-Smtp-Source: AK7set9U2ZBUFH/S31IhCYoHpquQjxURZuVi2kXr+bZ+pgh/GZzQ7tJnxjqtE1HnQqXcXzf64LKCLVX3qI8XwzrOGG0= X-Received: by 2002:a05:6871:6b97:b0:16e:2f74:e5c1 with SMTP id zh23-20020a0568716b9700b0016e2f74e5c1mr754057oab.8.1677237388597; Fri, 24 Feb 2023 03:16:28 -0800 (PST) In-Reply-To: <87wn479vj7.fsf@gmail.com> 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:256564 Archived-At: On Fri, Feb 24, 2023 at 11:01 AM Augusto Stoffel wrot= e: > > On Fri, 24 Feb 2023 at 10:20, Jo=C3=A3o T=C3=A1vora wrote: > > > The second thing I don't like is also due to the late-binding idea. > > This is a hotspot in Eglot, some of these functions are called > > many many times, for each LSP server interaction depending > > on how many document positions are exchanged (and they can > > be a lot). I do remember benchmarking strategies at the time > > and seeing a perceptible difference. Plus, this late-binding is > > really useless as a server will guaranteedly _not_ change its > > column-counting standard during the LSP session. > > `eglot-lsp-abiding-column' allocates a new string! I doubt that looking > up a few plists makes much of a difference compared to that. But when > using the better offset counting styles, I think it might indeed make a > difference. OTOH it might as well be premature optimization. And this is why we measure. You can find some scripts for doing that and some discussion in: https://github.com/joaotavora/eglot/pull/125 The 2018 issue where this all started. > > Finally, here's a patch that doesn't use late-binding, doesn't > > introduce new strategies and supports "utf-32" and "utf-16" > > today. As you can see, the patch is nearly trivial. > > I'm fine with that way of doing things, but please respond to my concern > from the other message: do you really want to store a server capability > in a buffer-local variable? What about your plans to support multiple > servers? The capability is stored in the server object and reflects in the buffer-lo= cal variable which will be restored when the session ends. I don't see any problem with that. My idea of supporting multiple servers is to create a proxy program that invokes multiple processes and negotiates a common set of capabilities, so I don't see it as a problem either. If server A suppor= ts utf-32 and utf-16 and server B only supports utf-16, the multiplexing server C only declares support for utf-16. > I suggest you to guard against future headaches. We can store the > offset functions in two slots of the server class if you don't like to > traverse the capabilities plist each time. No, this is exactly the type of complexity that I strive to avoid in Eglot, especially when the added value is small. Jo=C3=A3o