From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#70541: track-changes-mode logs warnings (with input method, in Eglot buffer) Date: Mon, 29 Apr 2024 16:50:07 -0400 Message-ID: References: <86ttjr2pzw.fsf@gnu.org> <86edau3gyy.fsf@gnu.org> <8634ra36ny.fsf@gnu.org> <861q6ou2cs.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8486"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: rcopley@gmail.com, 70541@debbugs.gnu.org, joaotavora@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 29 22:53:55 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 1s1Y0Z-000215-05 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Apr 2024 22:53:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1Y0P-000175-3Y; Mon, 29 Apr 2024 16:53:45 -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 1s1Y0N-00016m-2y for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 16:53: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 1s1Y0M-0005Jz-Qn for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 16:53:42 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s1Y0g-00037s-E9 for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2024 16:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Apr 2024 20:54: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.171442402112010 (code B ref 70541); Mon, 29 Apr 2024 20:54:02 +0000 Original-Received: (at 70541) by debbugs.gnu.org; 29 Apr 2024 20:53:41 +0000 Original-Received: from localhost ([127.0.0.1]:58783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1Y0K-00037e-TM for submit@debbugs.gnu.org; Mon, 29 Apr 2024 16:53:41 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10627) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1Y0E-00037W-P2 for 70541@debbugs.gnu.org; Mon, 29 Apr 2024 16:53:38 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C327A1001E4; Mon, 29 Apr 2024 16:53:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1714423987; bh=rkmHwPjfhqaOKCeHYt8Dgejjevi/DG3lk+7P2wZMecE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fx61X+ZgL4tfYlqKyLxZopYl6Bbp+Sul7ixxAy9ayTRFnwM955P3y/95SnUAjacas Gp/5s9sisqmqyLTb/VgjCDYCZUPcpKEuxD7ajMKToy8e2/YFWf/mhiqFB4YqqLyNQF kF113WphSrH7EZyNdE4J1se1aMPcOhVmTLNQDVFp/ElONAzeesGnagisPqCp7OkSSU iXC9ATwCTWDPfYcqRlqWDvdaJZZU1L6J8QEYNATUZ6XQ6SapATKLfj7Dr6bQEoJ/YJ w6BlkxZGYA/DDFp4U24VcAKglOVRY5XTkyBU+XUHOLwyzQThzs+tC/3ncO7nj2pH/v 9KfawGv5JLVtQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7A4D91000AD; Mon, 29 Apr 2024 16:53:07 -0400 (EDT) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 69F74120191; Mon, 29 Apr 2024 16:53:07 -0400 (EDT) In-Reply-To: <861q6ou2cs.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 29 Apr 2024 09:09:23 +0300") 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:284177 Archived-At: >> >> 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. While we can think of it as ephemeral, the fact is that it lasts through redisplay, running timers, etc... So it's not at all obvious why it should be treated differently from the case where the users type something and then hit undo because they realize they made a mistake, or when they type a short string followed by `M-x expand-abbrev`. There are many other forms of "ephemeral" changes, where we don't inhibit modification hooks. E.g. in `replace-match` we sometimes insert the replacement and then capitalize it. The intermediate non-capitalized string is very much ephemeral: much more ephemeral than Quail's (there's *very* little code run between the two operations). Yet we call `before/after-change-functions` separately for both changes, thereby exposing the intermediate state. > So those insertions followed by deletions are not meant to change the > buffer, Yet they do. > and should therefore be ignored. I don't understand the "therefore". Also, ignored by what? Clearly they should not be ignored by redisplay (since the whole purpose is to give guidance to the users). Also, currently they're not ignored by `font-lock`. Is that a bug? >> 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? It's a performance bug. >> 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? It doesn't: it reacts to the changes in an idle timer. But the idle timer can see Quail's intermediate state, exactly because it is not nearly as ephemeral as would be needed for `with-silent-modifications` to be acceptable. > 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. Eglot could pause its work during Quail input. But note that with some input methods, being in the middle of a Quail input can be very common, so it's not a great solution because it could unduly delay the work of Eglot. And of course, other packages may not have that luxury. > 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? I definitely would not want Track-Changes to lookup a Quail variable. We should instead use/introduce some package-neutral var (which other packages could use). But I'd first like to know why it is that Quail needs `inhibit-modification-hooks` to make sure we really need such a workaround. [ BTW, let-binding some dynbound variable would not do since track-changes would not see it if called from a separate thread. It would have to be a buffer-local var. ] Stefan