From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70541: track-changes-mode logs warnings (with input method, in Eglot buffer) Date: Wed, 24 Apr 2024 18:42:13 +0300 Message-ID: <86edau3gyy.fsf@gnu.org> References: <86ttjr2pzw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21970"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rcopley@gmail.com, 70541@debbugs.gnu.org, joaotavora@gmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 24 17:44:09 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 1rzen3-0005XL-D7 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Apr 2024 17:44:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzemh-00012D-Hi; Wed, 24 Apr 2024 11:43:47 -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 1rzemf-00011p-S4 for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 11:43:46 -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 1rzemf-0006as-JZ for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 11:43:45 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rzemw-00046p-F8 for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 11:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Apr 2024 15:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70541 X-GNU-PR-Package: emacs Original-Received: via spool by 70541-submit@debbugs.gnu.org id=B70541.171397339615332 (code B ref 70541); Wed, 24 Apr 2024 15:44:02 +0000 Original-Received: (at 70541) by debbugs.gnu.org; 24 Apr 2024 15:43:16 +0000 Original-Received: from localhost ([127.0.0.1]:59056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzem6-0003yC-V8 for submit@debbugs.gnu.org; Wed, 24 Apr 2024 11:43:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzelz-0003vg-PE for 70541@debbugs.gnu.org; Wed, 24 Apr 2024 11:43:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rzeld-0006RI-1l; Wed, 24 Apr 2024 11:42:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=+Kkprf5WgOclVo7F0eCaTv9HyzyBY6ys298sKD2yg5o=; b=RKSwAyGYJrUAMWSxSaYE 1Z3WMDFBqzCkRGZ/iuUwClzX6yidInebOM0aSKORoZPfxbKl9tpy/cShSS3QZhKFm/twoYo0HR5n2 Eqyn112gFv2I8Mep3TIEZ8bxn009VzOHVR/6MSF/iwSPG8sTn/HTFbklsslEZhTLLgrDMlkVChvCO RkUJfhmSVYlGpIXO0grDgCMXa8YQpf6YAuq+SJkqA0j+YFgRXp8C6HxPjQf6zhuA8ySsY2EQS8AJ0 Eph2AlmEY2veWFQf4vny5Nt3Loj7fVNmKTRUFvJxoxZn0v5I4QqAFp6mK2iUR+0QFfpmosdJ1Xh1C H1d8LcUdpf9KXw==; In-Reply-To: (message from Stefan Monnier on Wed, 24 Apr 2024 10:26:40 -0400) 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:283921 Archived-At: > From: Stefan Monnier > Cc: rcopley@gmail.com, 70541@debbugs.gnu.org, joaotavora@gmail.com > Date: Wed, 24 Apr 2024 10:26:40 -0400 > > > Are you sure we want buffer-change hooks to be called here? > > Adding/removing chars from the buffer without running those hooks breaks > all kinds of assumptions. It can be acceptable to do it in a very > temporary way, but Quail doesn't do it temporarily: the whole > redisplay+timers+filters gets run in the middle of the input of any > multi-key entry like `^a`, so the "temporary" state is very > much exposed. It's exposed to some parts of Emacs, but not to others. > > Quail intentionally hides some of the modifications it does, because > > it many times replaces the inserted text with something else, and from > > the Emacs Lisp program's POV only the final input is the actual > > "insertion" Emacs should know about. > > I'm not sure why it's important to hide the intermediate steps, Because Quail emulates keyboard input. Conceptually, everything that the user types into a buffer that Quail processes and replaces "did not happen", only the final insertion of the produced character(s) are real. > especially since they're not very well hidden (as evidenced by this bug > report, and by the fact that font-lock is also triggered every time the > transient display is modified). Actually, it's hidden quite well, it's just that Eglot gets confused because it looks at stuff it isn't supposed to see ;-) > Note that when users use Abbrev instead to turn \lambda into λ, the > intermediate steps are not hidden, and that's not been a problem. Abbrev cannot guide the user regarding the next steps when an initial string typed by user has several possible candidates for further input. So Abbrev basically solves a simpler problem. > > So I'm not sure we should install this, as it could break something > > elsewhere. Aren't there any alternatives to this? > > We could change Quail so it refrains from temporarily modifying the > buffer, using an `after/before-string` on an overlay instead. > It'd be a fairly significant change in `quail.el` and would probably > come with its own share of problems. I'm not at all sure the solution should be in Quail. > > More generally, > > why should Eglot care about these low-level details of Quail? > > Because Eglot syncs up with the LSP server via a timer, so it sees the > buffer with an extra "^" char in it. So maybe Eglot should learn that when it sees this and a Quail input is in progress, it should pretend it didn't see anything? IOW, why not solve this in Eglot instead? It's Eglot that makes incorrect assumptions about what happens, so let's teach Eglot how to do better.