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#73863: 30.0.91; Unexpected cursor movement with flymake-show-diagnostics-at-end-of-line Date: Sun, 20 Oct 2024 18:49:27 +0300 Message-ID: <86froqixko.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4946"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, 73863@debbugs.gnu.org, joaotavora@gmail.com To: Romain Ouabdelkader Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 20 17:50:54 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 1t2YCj-00014A-1W for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 20 Oct 2024 17:50:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t2YCU-0002yO-6K; Sun, 20 Oct 2024 11:50:38 -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 1t2YCS-0002yE-Py for bug-gnu-emacs@gnu.org; Sun, 20 Oct 2024 11:50:36 -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 1t2YCS-0005Ck-Gw for bug-gnu-emacs@gnu.org; Sun, 20 Oct 2024 11:50:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=Bnx3igfTGnf/YhbfYEeMOefKSsp8DJ4dHUkMAsAx5Xo=; b=GtsQT5cp92ye2Nff40iu0Gs9v7s+BSMwCk9TtBd/UURQ4AgqSRmF77600v03n47IR5f6PEjxUz8IlgDA0abSwiNjiRI4zO8GdL/4gkH9KQqe0nnsmKnCB6uBqCrapPEJrNsLuGUupkB1eLpGy++9Q21jx8EkAXA2jCkwQkP9zvLNbTep/D+GkrME0AxuEHhOWlqaKRtfpIKec3l3cWhe4IhsfnjWUaHksftS5gyRZD4WlF7f9wJbFJVc68QyPWKmg2TubaC3WWD3w2kUR9de+aEPDaOy9XrxbosdCrzAySiUfnuKE31W6Zt98SDeMpjkzPwhsTo8GP5UlYhVALv6JA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t2YCr-000730-MP for bug-gnu-emacs@gnu.org; Sun, 20 Oct 2024 11:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Oct 2024 15:51:01 +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.172943940526648 (code B ref 73863); Sun, 20 Oct 2024 15:51:01 +0000 Original-Received: (at 73863) by debbugs.gnu.org; 20 Oct 2024 15:50:05 +0000 Original-Received: from localhost ([127.0.0.1]:48176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2YBw-0006vk-K7 for submit@debbugs.gnu.org; Sun, 20 Oct 2024 11:50:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2YBu-0006v7-MY for 73863@debbugs.gnu.org; Sun, 20 Oct 2024 11:50:03 -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 1t2YBP-0004wV-JZ; Sun, 20 Oct 2024 11:49:31 -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=Bnx3igfTGnf/YhbfYEeMOefKSsp8DJ4dHUkMAsAx5Xo=; b=ZWySFBNqf6bm ++K6tz+85kKlRBL1Id99yDwIlPX1tQb/exm5EzImID9IIpmVToPmHPpZ4qONGEVhK+quvkVnkmh5p dMz5Eotcnd/QFIxQ8efJp8lIRvWiNav4XWyTUNAxLU7XLHhvTQtdKspzWxcz9QkMWASa+Bv+6U7p2 5eHd03Mvxl8+XxArMJAgTFl92h5sovcixtGCU2IPtBGTxkAdDLKwJPivECPX+DSFoy4PryvAngCg2 ytt3RbcL+4JIJBbpMpzJac2Qf6h7bXAI8FdCO9PiG6ukzr0LrnQJ/0uM4BzrWfkGW+I8wG9o+x4kG wqaGbYiZozxed4ZlIJBR7A==; In-Reply-To: (message from Romain Ouabdelkader on Sun, 20 Oct 2024 17:01:44 +0200) 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:293981 Archived-At: > From: Romain Ouabdelkader > Date: Sun, 20 Oct 2024 17:01:44 +0200 > Cc: Eli Zaretskii , sbaugh@janestreet.com, 73863@debbugs.gnu.org > > 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. That's not possible, because the diagnostic is displayed using an overlay string, and Emacs cannot show a cursor inside such a string unless a Lisp program tells it exactly where to put the cursor. IOW, for the cursor-positioning purposes, overlay strings are considered as indivisible chunks of display. > 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 Under the default value of line-move-visual, this is not possible: Emacs is required to show the cursor inside the next _screen_ line, not the next _logical_ line. Compare that with the situation where the diagnostic string is part of buffer text -- in that case you'd want the cursor to end up inside the next screen line, which is wrapped from the long line starting with "unknown_function". > 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. It isn't feasible. > 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 We could have the cursor after the diagnostic, if we don't put the 'cursor' property at all. So these are the possible solutions for this situation: . don't change anything and live with the minor irregularity in the cursor positioning in what I consider to be rare cases - variation: turn on truncate-lines in such cases . don't put the 'cursor' property on the diagnostic, in which case C-n will place the cursor after the end of the diagnostic on the screen line where the diagnostic ends . put the 'cursor' property at the last character of the diagnostic string, and have it displayed there . calculate the character on which to put the 'cursor' property dynamically using some convoluted logic . implement display of diagnostics in a tooltip instead Any other suggestions?