From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#73863: 30.0.91; Unexpected cursor movement with flymake-show-diagnostics-at-end-of-line Date: Tue, 12 Nov 2024 16:38:43 -0500 Message-ID: References: <86r08dmm0h.fsf@gnu.org> <86plnxmfdt.fsf@gnu.org> <86y12kjks0.fsf@gnu.org> <86a5ezjkx8.fsf@gnu.org> <86zfmzhvdb.fsf@gnu.org> <86wmi3hu4o.fsf@gnu.org> Reply-To: Spencer Baugh Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11234"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 73863@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Romain Ouabdelkader Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 12 22:39:15 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 1tAybS-0002mD-HF for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Nov 2024 22:39:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tAybH-0001bb-S9; Tue, 12 Nov 2024 16:39:03 -0500 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 1tAybG-0001bR-RH for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2024 16:39:02 -0500 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 1tAybG-0005db-JC for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2024 16:39:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=yF/Gm83s/ByChSC9tIhhbaWFhyOJKOT+Nwk8+ZJK7ks=; b=jbynWyMPCtD/eZXJhrbpOFke2LEbJOaPEdzUk/dEeW+gchUImWeJm6oPM5Gb8yMZ/k3iymeRhV2TTa3pWDLPG1SZuG84JsZd7NgYm3Q1S6zx9JwqKOrgk5IOECeRiGvuIgyW9Zuuj67eUa0P2hKIUw/8fPcySoe24SfcPiASqpFjnQoWTz9X6zK4vQ/QoS22UIqTjmCN34Uz5xXX9oeTDT72kWNxYtoUu32nG27eHPN7TkwNApjxxeHoWTxrZGpa7olZQh1nd3j9Ij+Vqv4IzJlQ0X/5V+gVi49C8bme/f2DKLQDpKCOVCX2ELb7sWB6lUTySvbcWA+eWVgAzPBIrg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tAybG-0006B3-66 for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2024 16:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2024 21:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73863 X-GNU-PR-Package: emacs Original-Received: via spool by 73863-submit@debbugs.gnu.org id=B73863.173144753123720 (code B ref 73863); Tue, 12 Nov 2024 21:39:02 +0000 Original-Received: (at 73863) by debbugs.gnu.org; 12 Nov 2024 21:38:51 +0000 Original-Received: from localhost ([127.0.0.1]:39732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAyb4-0006AV-JX for submit@debbugs.gnu.org; Tue, 12 Nov 2024 16:38:51 -0500 Original-Received: from mxout6.mail.janestreet.com ([64.215.233.21]:45369) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAyb3-0006AJ-Gp for 73863@debbugs.gnu.org; Tue, 12 Nov 2024 16:38:50 -0500 In-Reply-To: (Romain Ouabdelkader's message of "Sun, 20 Oct 2024 17:01:44 +0200") DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1731447524; bh=yF/Gm83s/ByChSC9tIhhbaWFhyOJKOT+Nwk8+ZJK7ks=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=W598WBxvuwNCtn5ANzLo4kBJzQz84ejv2o8Cl6EE2NZBRHTt7m0PS1wjaSyKJ59rx xDBGi8bD7vRrTUhAWJzkv+HlWTEd793Ws1fwzLNhdYniG+lttsMu+X1Qo6MqEREdGv SjP1JoQrMwWsEotCmauC6TN0BmuKot69ZBUnUI++26d/z45Cz2GhvhYODUDgKkd4p7 BPx9NDDGlYgKL+jezcoIzUOxvYpc8XRkSd3PBZFEJZbnsw5YIjBvbT67p8ukTW0bAO hH5omZAlcxzd7tBhS/pCH2v4DBSgBwRccqmqbUrM6tLFbtQ7DMnCgexbeUdteT5WFl miMTDEc5o5vGw== 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:295253 Archived-At: Romain Ouabdelkader writes: > Sorry, I realized I wasn't clear about the behavior I was expecting. > > I would expect the cursor behavior to remain consistent whether diagnostics are present or not, especially since diagnostics can > appear and disappear during editing. > > For example: > Screenshot 2024-10-20 at 16.56.48.png > Here, when press C-n once, I expect the cursor to go here: > Screenshot 2024-10-20 at 16.57.59.png > > I.e. the behavior would be the same as if there were no diagnostics in the buffer. > I'm not sure if that's actually feasible or if there is an issue with this behavior. I think that's indeed the ideal. > I tried your patch but it makes the cursor go on the diagnostic which i find surprising, I believe the cursor should not be able to > move into a diagnostic: > Screenshot 2024-10-20 at 17.00.18.png > > What do you think? I think this behavior is bad, so I don't think this is a good patch. Note especially that C-e puts point after the diagnostic, then DEL deletes characters before the diagnostic! Unexpected and confusing IMO. That's equivalent to the behavior without the 'cursor property: point goes to the end of the displayed diagnostic, both on C-e and C-n. There are two conflicting issues here: A. Having "point is at EOL" be displayed as "the cursor is after the diagnostic" is unacceptable because it means DEL deletes characters at a distance, and other similar bad issues. So we want "point is at EOL" to be displayed as "the cursor is before the diagnostic", which the existing 'cursor property achieves. B. (vertical-motion 1) tries to move the cursor to after the diagnostic, since that's the next screen line. Then the cursor property displays the cursor back to before the diagnostic. Since that ends up moving point to the end of the current line, which is the same visual line, this is unexpected. A is more important than B, so if we want to fix B we can't break A. Here's a self-contained demonstration without flymake: (with-current-buffer (get-buffer-create "*overlay-demonstration*") (erase-buffer) (remove-overlays) (insert (make-string 80 ?x)) (save-excursion (newline) (insert (make-string 80 ?y))) (let ((ol (make-overlay (point) (1+ (point)))) (s (propertize (make-string 80 ?s) 'face 'warning))) (put-text-property 0 1 'cursor t s) (overlay-put ol 'before-string s)) (delete-other-windows) (let ((win (split-window-right -62))) (set-window-buffer win (current-buffer))) (other-window 1)) If you run this then you'll observe behavior B when moving with C-n and C-p. There's actually another symmetric issue to B: after moving to the end of the line with C-e, if you hit C-p that moves to the start of the current screen line, instead of moving to the previous screen line. This is because vertical-motion acts as if the cursor is on screen line 3, when it's actually on screen line 2 because of the 'cursor property. Arguably this is a bug in vertical-motion: if you run (vertical-motion 1) or (vertical-motion -1) in the appropriate places, it returns 1 or -1, claiming that it moved by a screen line even though it actually stayed on the same screen line. I'm not sure how to fix this. IMO, vertical-motion should try harder to move by screen lines. In the C-p case, there's an obviously correct thing to do: move to the same column of the previous screen line. But for some reason, vertical-motion doesn't do it: it stays on the same screen line. Maybe fixing this should start there?