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: Wed, 24 Apr 2024 15:02:47 -0400 Message-ID: References: <86ttjr2pzw.fsf@gnu.org> <86edau3gyy.fsf@gnu.org> Reply-To: Stefan Monnier 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="12427"; 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 Wed Apr 24 21:07:04 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 1rzhxP-0002v4-Mj for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Apr 2024 21:07:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzhxB-0005AD-DM; Wed, 24 Apr 2024 15:06:49 -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 1rzhx9-00059r-Vz for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 15:06:48 -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 1rzhx9-0005SV-Li for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 15:06:47 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rzhxQ-0000v9-Nq for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 15:07:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Apr 2024 19:07: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.17139855763057 (code B ref 70541); Wed, 24 Apr 2024 19:07:04 +0000 Original-Received: (at 70541) by debbugs.gnu.org; 24 Apr 2024 19:06:16 +0000 Original-Received: from localhost ([127.0.0.1]:59959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzhwb-0000mm-ID for submit@debbugs.gnu.org; Wed, 24 Apr 2024 15:06:16 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39743) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzhwU-0000kN-Po for 70541@debbugs.gnu.org; Wed, 24 Apr 2024 15:06:11 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 52C1A442855; Wed, 24 Apr 2024 15:05:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1713985541; bh=gHEnBWKv5Vnq1xuhPQ/2ZyaG6TtVz+cCWudKD20MasE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=l0XGiRWDy32QUYLoO6pFJCnZt0tDcPWtAXbwNv3n5NaTLzT+iED+6oQswCqk24yuo 0cip1D47Z6wzqy8THgBzqGzwPOfvgoqoTPUJuQ2Vb3mIxB0kF2qzjullbEUqkFXr2p t3XyFcASTlLwvy92jyCE9vzbproqo5jymPMY4iGljQPX1bvFuszWHk014p+J7DHthN WIl+aSbM7shfuDEIC+GVGe3MEy2F13d0w1jXLkVJf0pqXwQT3nHO27Ne8KAt3e2HzO HdqlQ3F0SsBZzlRbR8GkcRbAXvF/7klXrG8jX8oTB6Zk3P5z62TNFW2y5G/a4eQhSW cuPx8ZJn305gA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D31FD442848; Wed, 24 Apr 2024 15:05:41 -0400 (EDT) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BF868120610; Wed, 24 Apr 2024 15:05:41 -0400 (EDT) In-Reply-To: <86edau3gyy.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 24 Apr 2024 18:42:13 +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:283927 Archived-At: > 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? Tree-sitter is told about it, font-lock is told about it, why not others via the usual mechanism? What's different about Eglot? >> Note that when users use Abbrev instead to turn \lambda into =CE=BB, 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. When combined with appropriate completion tables and UIs, abbrev also guide the user, so it's not that different. Also, I fail to see how that's relevant. The buffer state is modified by Quail. It's somewhat temporary but there's still a lot that can happen during that temporary state. > 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. And how are they going to deal with it? 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 `^`). This is pretty ugly in my book, sounds like workarounds on top of workarounds. Can we try the patch I suggested first? 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. > 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. Stefan