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 22:24:49 +0300 Message-ID: <8634ra36ny.fsf@gnu.org> References: <86ttjr2pzw.fsf@gnu.org> <86edau3gyy.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3103"; 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 21:26:18 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 1rziG1-0000Y9-26 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Apr 2024 21:26:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rziFd-0001Rj-Tx; Wed, 24 Apr 2024 15:25:53 -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 1rziFZ-0001RA-53 for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 15:25:49 -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 1rziFX-0003Wm-ST for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 15:25:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rziFo-00048F-ND for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 15:26:04 -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 19:26:04 +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.171398672715465 (code B ref 70541); Wed, 24 Apr 2024 19:26:04 +0000 Original-Received: (at 70541) by debbugs.gnu.org; 24 Apr 2024 19:25:27 +0000 Original-Received: from localhost ([127.0.0.1]:60048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rziFA-00040x-Ih for submit@debbugs.gnu.org; Wed, 24 Apr 2024 15:25:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52480) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rziF5-0003zo-5J for 70541@debbugs.gnu.org; Wed, 24 Apr 2024 15:25:23 -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 1rziEf-0003Ab-Rq; Wed, 24 Apr 2024 15:24:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=rmvZ20ttM47Q5B0zPeiiU60TmUGoy0xEFg23Gtt3F/c=; b=Io8Uh4PKGS27 LDYgDlaq8vL9JOe5o+R8oPYaj36tdBuw5txIIh9DXWJZ6sVnCdzpL1W0Qxt3cV8OEeOlxa33ttpxH t09NHCeji2I+X4sKoRJQDXs33wO69VUCGeuAQc+23d0N6FJfwykjDpW9F5DDWp3v0SyGFYgcLHOAO gxXln+ACNW7dbBT7axB0S/fOV/znhT04RzdlJQng408mA+DSn8s9V0IUgxHISK9gk/A4ix/3YxvIn 5WiNOz6PFtXM9x4Y8YQuWdTHkTE/VtO1TI/s9Af9OR9ZqAiAu5KNz0d23HQVqpJgUw1Ins8DsdpqU UxLbA+WqrVc68iyDP/tMvw==; In-Reply-To: (message from Stefan Monnier on Wed, 24 Apr 2024 15:02:47 -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:283928 Archived-At: > From: Stefan Monnier > Cc: rcopley@gmail.com, 70541@debbugs.gnu.org, joaotavora@gmail.com > Date: Wed, 24 Apr 2024 15:02:47 -0400 > > > Actually, it's hidden quite well, it's just that Eglot gets confused > > because it looks at stuff it isn't supposed to see ;-) > > Who's supposed to see it and who isn't? Those who need to know are supposed to see, the rest aren't ;-) Seriously, though: > 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. > > 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? It worked fine before that, with the same Quail, right? Or am I missing something? And why "yucky"? This is the same Quail in all those cases, and the same track-changes machinery. So if Quail gets in the way of track-changes, how about if Quail sets some flag which tells the application level that changes in progress are to be ignored? If we can handle that as part of track-changes, fine; otherwise, Eglot and the rest that use track-changes will have to ignore that on the application level. Doesn't sound yucky to me. > And how are they going to deal with it? By ignoring the changes performed while that flag is set. > The only sane way I can see to deal with it would be for Quail to > provide a way to temporarily return to the "real" state (e.g. deleting > the `^`) and then to get back to the temporary state (i.e. re-insert the > `^`). Why is it not enough to ignore the changes? > 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? > It makes more code normal instead of adding more special code to deal > with special code, so if that works it's a much nicer option. Once again: Quail uses with-silent-modifications for a reason. You are basically suggesting to ignore that reason, and hwy? because it makes the solution much easier? A simpler solution is only preferable when we know for sure it is correct, and here we are just guessing, since we don't really have a clear idea what will that cause in other cases. > > 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. > > I don't think these are incorrect assumptions because there's not much > else it could do. If packages like Eglot can't do their work correctly > without knowing about Quail, I think it means we have a poor API. I'm suggesting a way for Quail to tell those applications that it is in the process of making changes that should be ignored. If such a mechanism is possible, I think those applications could DTRT without much effort. Or am I missing something?