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#70929: 30.0.50; eglot--apply-text-edits prevents point adjustment Date: Tue, 14 May 2024 15:16:11 +0100 Message-ID: References: <86seykx66p.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="8731"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 70929@debbugs.gnu.org To: Troy Brown Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 14 16:18:47 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 1s6szO-00022v-6l for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 May 2024 16:18:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s6sz6-0002WK-U8; Tue, 14 May 2024 10:18:28 -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 1s6syf-0002VN-DW for bug-gnu-emacs@gnu.org; Tue, 14 May 2024 10:18:01 -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 1s6sye-0008Rj-Sa for bug-gnu-emacs@gnu.org; Tue, 14 May 2024 10:18:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s6syf-0005lG-JZ for bug-gnu-emacs@gnu.org; Tue, 14 May 2024 10:18:01 -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: Tue, 14 May 2024 14:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70929 X-GNU-PR-Package: emacs Original-Received: via spool by 70929-submit@debbugs.gnu.org id=B70929.171569625922137 (code B ref 70929); Tue, 14 May 2024 14:18:01 +0000 Original-Received: (at 70929) by debbugs.gnu.org; 14 May 2024 14:17:39 +0000 Original-Received: from localhost ([127.0.0.1]:39631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s6syG-0005kz-IR for submit@debbugs.gnu.org; Tue, 14 May 2024 10:17:39 -0400 Original-Received: from mail-lj1-f171.google.com ([209.85.208.171]:57463) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s6syB-0005kl-NW for 70929@debbugs.gnu.org; Tue, 14 May 2024 10:17:35 -0400 Original-Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-2e5218112a6so47011131fa.2 for <70929@debbugs.gnu.org>; Tue, 14 May 2024 07:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715696184; x=1716300984; 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=h5GvSv6ikiXsCd7rTDLaeHVQe/d1Qh1tqjKsu3hU69I=; b=I4GgDU6GzE7olT0+zNc7ifImO2AZgTzc70gsnxsDhmFfu5pZj/9eCf5vTS2Ww/nOvQ YKUen9oRsUxmXdIAr7dmVmKdHXfnozJYUeIENbRdWh2PXHhNgExqlEs96J4Sy1cbbf4f 59HNNAzgZyYPrVAy5nwGM+b+XfFhO6jfRqK7qn+DPmbMWpHlF1JTOuSBm8d8qfxrCFfk yXojFtclgYGsA6kRceFCaH+x0HYMPnta+v5g7jwRssQokHCkhv2JDJZg67CY+sdUJI4u Uucoh1jYFe76VfhDez5YPlU0IVSJF05XtoNpwimz65c4TL3hNsNXBZ4w4muaet7zdb1o qbNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715696184; x=1716300984; 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=h5GvSv6ikiXsCd7rTDLaeHVQe/d1Qh1tqjKsu3hU69I=; b=Ry1+y65fOXI/WYdad+DaIoWAavPYH2DBfwhoVVu4pi7l6vhOdA53jtf1SY39jsnxCG LEzvBT91qV6A+nsf3q1Vfs+9fpRF2p+EGTaLly5+MtqSIpycKVv77kfL0lKx5E5UYvHL 03V1TbnDOG+aupWSWo4rTSspc+VnSCAKEUJ1wxPWl/kAh4Bqjn0DnSYIGFSHMGG4okcm F4FG7jAciyuNnHgpr2hYpKbNL2rNUvNicnq0m5wN2rgJk0PwnAoSExiOzm97FgDuXGsK fT3EU1mlHpvsBVEd5g5RxOO7mF8dIOGgwHfwMHoIORG7B/3l/XgZXtbpSBKj513Km+d/ tA7w== X-Forwarded-Encrypted: i=1; AJvYcCWwryHV3vBvn2BHUgp/WSc60RslkKsQpy44YbC9998vY2JpcMRhhN+7aiQM+Dx2YtbLEtVA2j/WyhsFuzp+AIKJhCey+LM= X-Gm-Message-State: AOJu0Yw1WI5FKeYKcOJPwJUBrnE0cXon75lkSfevQCGTEWNwelRp74U/ Jo1eBA3BFZ95FPAkW/MNAjAvGJKx3NOrvZDQOTEbS2qAR9+H2TA/3Jk5saOvVFZvijYqT43sY8/ Jx2pVK+QjUMFHx2THXh2g9tA1j3I= X-Google-Smtp-Source: AGHT+IFEMLTNUq6x3UykWjbNiqdPmMRFUPe/PPSngo8PKbn19pUYwzMDMYWlUXTZoVbgagK31VPkzjykMO/4/tVan3A= X-Received: by 2002:a2e:91ce:0:b0:2df:1e3e:327f with SMTP id 38308e7fff4ca-2e52039bcb3mr90674381fa.38.1715696183900; Tue, 14 May 2024 07:16:23 -0700 (PDT) In-Reply-To: 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:285021 Archived-At: On Tue, May 14, 2024 at 1:44=E2=80=AFPM Troy Brown = wrote: > Possibly, although VSCode, which is probably considered the model LSP > client implementation, allows this to happen. Not saying it's > necessarily correct in doing so, just another data point. VSCode has its own mini-plugin for each language (sometimes not so mini). Akin to a major mode, but has somewhat less than 40 years of work put into it. In that aspect, it's not exactly a model of what LSP purports to bring: a language-agnostic solutions. So I don't model Eglot after VSCode, and have never done so. I model it aft= er LSP and my knowledge of Emacs. That's not to say that I will ignore if you show here whichever solution VSCode uses for this (if anything). > > The workaround of enabling electric-indent-mode or just turning off > > OnTypeFormatting > > via eglot-ignored-server-capabilities is much better. > > I'm not sure a workaround of turning this off is desirable if you're > trying to use it for indentation. If the mode doesn't have internal > indentation support, this will fallback to something like > indent-relative which might get you in the ballpark but won't be as > accurate as having the language server provide you with the correct > indentation. Sure, a workaround is not a solution, by definition. But the way to implement the solution in a LSP language-agnostic way -- which is what eglot.el does -- is murky right now. To gain confidence in any approach , I'd ideally first have to have unit tests running on say, 5 servers that support OnTypeFormatting. Code up those tests in test/lisp/progmodes/eglot-tests.el. Verify that the "after the point indentation" indentation cases all fail currently for those 5 servers and the "elsewhere changes" cases all pass. Then, get to coding a solution. For a successful solution all cases should pass. This is non-trivial work, so I'm not rushing to get started, especially since the electric-indent-mode workaround is pretty decent. For some meaning of "decent", at least :-) I find it relevant that so many users (including me) who are using OnTypeFormatting and never noticed this bug until today. But if you're interested, you (or anyone) could help get it started by surveying servers that support OnTypeFormatting, documenting how to install these 5 servers conveniently in a GNU/LInux system (perhaps a Docker image). This would make headway with the essential tests. You're even more welcome to write the tests yourself. As to the solution, maybe it would end up being something that relies on the status quo behaviour of the majority of servers like e.g. knowing that the "before point" indentation edit is always the last one (I'm just conjecturing here, no idea if don't know if this is the case). I don't like this kind of solution. Or maybe the solution is super-clean and is just about asking `replace-buffer-contents` to use the equivalent of `insert-before-markers` and proving it doesn't break anything anywhere else. Or maybe we can scale this up to the LSP folks so they help us understand exactly how this should work and maybe code it up in the standard, so serve= rs behave predictably. Jo=C3=A3o