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: Mon, 29 Apr 2024 09:09:23 +0300 Message-ID: <861q6ou2cs.fsf@gnu.org> References: <86ttjr2pzw.fsf@gnu.org> <86edau3gyy.fsf@gnu.org> <8634ra36ny.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="21419"; 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 Mon Apr 29 08:11: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 1s1KEH-0005O3-9n for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Apr 2024 08:11:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1KE2-0008Gm-Lk; Mon, 29 Apr 2024 02:10:56 -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 1s1KDr-0008Ea-Hh for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 02:10:43 -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 1s1KDq-0007rs-Vj for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 02:10:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s1KEA-00039S-IQ for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 02:11: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: Mon, 29 Apr 2024 06:11: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.171437101812103 (code B ref 70541); Mon, 29 Apr 2024 06:11:02 +0000 Original-Received: (at 70541) by debbugs.gnu.org; 29 Apr 2024 06:10:18 +0000 Original-Received: from localhost ([127.0.0.1]:55268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1KDS-000399-1i for submit@debbugs.gnu.org; Mon, 29 Apr 2024 02:10:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1KDQ-00038z-8S for 70541@debbugs.gnu.org; Mon, 29 Apr 2024 02:10:17 -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 1s1KD0-0007ST-9o; Mon, 29 Apr 2024 02:09:50 -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=Nr4AYWg+3d/E5R+yLCLqrtVdfbazfQUQLnTTWgBjBeo=; b=pgBlunj6A5f9aWYNPWyh r2q2RKF/X8ZKBd/D60xuS0UvlLkptXD5JnW/ZMYQV5VRCX4QvoY55dU42I5NXLY6k2CEvXukjNhpM VJmsBQ7YzrVmSGnaWR+y5fK/me6sY+7wYBESkUm3G2ZQpduGJiTF9sRoXE9TkXyBr3lxM7XYXqebD vztAee0mpG/4TEXctEP+RiFghJeo+YpXnDR/mg8pyRqk2eptrcbAUsOJXKeaMUbS+KYEt3bidWHGh SxKIIc95KeTsHwRpyAnIqv68hlCZKZmIYt56CclvBZXg/uOd/fTZajHsVFVrO7mL6Tppj15N94jhv 44SRZIwyqd1nrQ==; In-Reply-To: (message from Stefan Monnier on Sun, 28 Apr 2024 14:21:19 -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:284117 Archived-At: > From: Stefan Monnier > Cc: rcopley@gmail.com, 70541@debbugs.gnu.org, joaotavora@gmail.com > Date: Sun, 28 Apr 2024 14:21:19 -0400 > > >> The buffer state is modified by Quail. It's somewhat temporary but > >> there's still a lot that can happen during that temporary state. > > It isn't just temporary: it's a change that "isn't supposed to exist". > > It's just a side effect of how Quail is implemented. > > But what does it mean concretely? In which sense is it supposed not > to exist? > And more to the point, what makes it important to hide those changes? The actual change is the character(s) inserted when the Quail input function completes its job. Everything else is ephemeral, and Quail deletes it as part of its job. So those insertions followed by deletions are not meant to change the buffer, and should therefore be ignored. > >> > 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? > >> > >> That seems very yucky. Suddenly packages like Eglot, lsp-mode, crdt, > >> TeXpresso, CriticalMarkup, ... need to learn about that special > >> interaction with Quail. > > > > It isn't suddenly, it's because you switched Eglot to the new > > track-changes method, right? > > No, the problem was there before just as well. The difference is that > `track-changes.el` is more careful both to detect and to report > such problems. > > > It worked fine before that, with the same Quail, right? > > Yes and no: in some cases the old code failed to detect the problem and > that could result in broken behavior. When the old and new code detect > the problem, they both "work fine" in the sense that the behavior is > correct but at an extra cost because after detecting the inconsistency > Eglot does a full resync with the server. > > > Or am I missing something? > > It also works correctly with the new code. The difference is that we > report it (notice the `Subject:` says "warning"). > [ Note also that `track-changes.el` does not warn about it when running > in a released version of Emacs (see `track-changes-record-errors`), > because I assume it's less useful. ] So this is actually a non-issue? > >> And how are they going to deal with it? > > By ignoring the changes performed while that flag is set. > > Define "ignore". Do nothing and wait for the flag to become reset again. > The change are there. `point`, `point-max`, `current-column`, > etc... are affected. Why does Eglot need to react to those changes immediately when they happen? > >> This is pretty ugly in my book, sounds like workarounds on top > >> of workarounds. Can we try the patch I suggested first? > > We could try, but how many times do we need to make changes like that > > in Quail that bite us elsewhere before we learn the simple truth that > > we shouldn't try that anymore? > > Which other times are you referring to? For example, we made several changes in Quail and elsewhere to fix the recording of characters and the related keyboard-macro issues. It took quite some effort to get that right and fix all the regressions the initial too-naïve attempts caused elsewhere. So I'd very much prefer that Quail signaled to applications that it's in the middle of handling some complex input, and that applications which track changes ignored the changes made during this period. We might already have variables in Quail which could be used as such flags: quail-translating, quail-converting, quail-current-str, and quail-guidance-str, to name a few candidates. Could any of them be used for this purpose?