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 12:05:07 +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> <87pm9z9tfi.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="38387"; 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 13:06:15 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 1pVWq7-0009nb-BY for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Feb 2023 13:06:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVWpx-0006dJ-FX; Fri, 24 Feb 2023 07:06:05 -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 1pVWpu-0006ci-PQ for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 07:06:02 -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 1pVWpu-0007IY-Gs for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 07:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pVWpu-0007L9-Bs for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 07:06: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 12:06: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.167724032528166 (code B ref 61726); Fri, 24 Feb 2023 12:06:02 +0000 Original-Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:05:25 +0000 Original-Received: from localhost ([127.0.0.1]:36174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWpJ-0007KD-CP for submit@debbugs.gnu.org; Fri, 24 Feb 2023 07:05:25 -0500 Original-Received: from mail-oa1-f42.google.com ([209.85.160.42]:44910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWpH-0007Jy-QZ for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 07:05:24 -0500 Original-Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-1720600a5f0so19354696fac.11 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 04:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677240318; 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=fP7pQvpqSTBPlxmWsOn3Qg6Yfy4Lt/toBLUl0weXvyM=; b=S4rwER26oqAiM0IEjHPK1zf+04FGIs7iWeXjIY4zzw1iBygfkPRYJwqTpfhCIPqP3x 4UNX5M/EPINhiGJVM6X+0esazQfaGEzw7HJ4eck9BXpwR+l6sn1g1oYRplDMmrecw+P8 EoR5S9LJ4xVbLHoVAQ45Ptgxr2mmKXtQ7gxo+0Z5AFu+cKdKCZvuIxsqwxYGa7PruqR2 dloH48fKjHWBC9SfcmHoIrbnuVO6tm6w4CBY6kjCSclUND2ufSFW3fz+Ua8jig7pgW6T AnSBcHADpyUew0tgjnHn4kcxC3TvM7L6FlEQraGkmuFazm09A5rBpvQGX7kTUx0tlw4H 34BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677240318; 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=fP7pQvpqSTBPlxmWsOn3Qg6Yfy4Lt/toBLUl0weXvyM=; b=g9UfS/ZWIkMteO8YpE5EmP92j/960Xad4/aXYY8AXIEtQBovUYdKF498ZHtK1qXRrO rA2EiSy80J8CCebgfY0Ha0RCXDR8qyWGj43wueR9ejRrq/ickTfmZrq7IoqYlM9paIRH cp/NcXTdmlqjWuVY3t2m2JSkwV7dwVBegnDt1HIoiAyyD91qUoUYiMGekbduqYZsvuAp VH6O1b02JFjDe0fgvutEftTIzpJVmYU8mvaV5nai8YzTlNayrthjz3T1kh+1NSIW6stT bA32e383n8t32IhH+QpKmVUUGuUEA8y994qu+ExuM01vtSosv0n+wwmNhHkw0jA7Q+lq 1zew== X-Gm-Message-State: AO0yUKWlL7HEhWobpCbey45QwL/hSPwUg9HMOaSBJBcWFznQo1c4nrol bd2HXVT9IQkeRGrEcrnFVNDQzRVvPRL2kURuGlE= X-Google-Smtp-Source: AK7set/J5/Exhl2DRWkAOqRoutrFxnhSEWtyQ39jcRxTLaL7oL7pMi4zO/jbGB7/1wvKHZAoSiEcIQGrVvyg5b7j+9s= X-Received: by 2002:a05:6870:3a34:b0:16a:17d9:b66d with SMTP id du52-20020a0568703a3400b0016a17d9b66dmr950869oab.8.1677240318269; Fri, 24 Feb 2023 04:05:18 -0800 (PST) In-Reply-To: <87pm9z9tfi.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:256577 Archived-At: On Fri, Feb 24, 2023 at 11:47 AM Augusto Stoffel wrot= e: > > On Fri, 24 Feb 2023 at 11:18, Jo=C3=A3o T=C3=A1vora wrote: > > > The capability is stored in the server object and reflects in the buffe= r-local > > variable which will be restored when the session ends. I don't see > > any problem with that. > > No problem, let's use your approach then. > > >> 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 Eg= lot, > > especially when the added value is small. > > You see how =E2=80=9Ccomplexity=E2=80=9D can be a subjective perception..= . To me, > entangling things is a hallmark of complexity, and you are entangling > server information with buffer information here. OTOH, adding a slot > that is set in 1 place and read in 1 place doesn't feel like complexity > at all to me. Very true, it's subjective. But both of our approaches are using multiple levels of removal from the source of truth. The source of truth is in the server, then it's cached in eglot--capabilities. Then I propose another level, cache it a buffer-local value, and you also propose another level, cache it an additional slot of the server. And don't forget that the "server" is _also_ hiding behind an indirection, the eglot--current-server function and buffer variable. What IMO makes your solution more complex is that the new alternate place of caching will not cause eglot-move-to-column-function and eglot-current-column-function to be deleted. We can't delete, even if we wanted to, because of backward compatibility. If you could, I would agree that our two solutions are of similar complexity. But that's not the reality. Jo=C3=A3o