From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Romain Ouabdelkader Newsgroups: gmane.emacs.bugs Subject: bug#73863: 30.0.91; Unexpected cursor movement with flymake-show-diagnostics-at-end-of-line Date: Thu, 31 Oct 2024 00:57:20 +0100 Message-ID: References: <86r08dmm0h.fsf@gnu.org> <86plnxmfdt.fsf@gnu.org> <86y12kjks0.fsf@gnu.org> <86a5ezjkx8.fsf@gnu.org> <86zfmzhvdb.fsf@gnu.org> <865xpdak64.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009742a60625ba7842" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17038"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, 73863@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 Thu Oct 31 01:00:27 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 1t6Ibz-0004Jq-D1 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 31 Oct 2024 01:00:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t6Ibd-0002CA-NZ; Wed, 30 Oct 2024 20:00:05 -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 1t6Iba-0002B7-PP for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 20:00:02 -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 1t6Iba-0005jf-Fi for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 20:00:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=t8xUTrVgUR/kjFVmQC9nELqdlUrfWAL0IM12qvVLWGw=; b=u3Pdi5yeNszCfSgI153uEFcthhvlxJk6pKRIiqPz9kLZRwBoCbvIDOuIQp4Fh/0PlGEj+wFeMw79+ZNCkZ7i/5iUtZbtilxqzte/tA9HvU96xGb8ab37aD41JGJWibWWtdrUl/zG8mS0xr3ytnFl3ohaNTelKpJ92Y3LWHK+hWKhUrf1Mhct3QSnELq7jjXj2C19VXFIA5wSWk0ciVn02rwMrDU4ZPSWhR/GIC6DbgUrzdMlXmPCda2Dgrq89F/PtolBwj28xPG1E/uZZmU4uI96YW6oRK8V97ctw5W8sW7pajj8jtHgGsGR9vYDm8JHHE9u6iudBLbWO7T+4oktpA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t6Iba-0006Xg-2d for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2024 20:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Romain Ouabdelkader Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Oct 2024 00:00: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.173033274925084 (code B ref 73863); Thu, 31 Oct 2024 00:00:02 +0000 Original-Received: (at 73863) by debbugs.gnu.org; 30 Oct 2024 23:59:09 +0000 Original-Received: from localhost ([127.0.0.1]:38348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6Iai-0006WW-N2 for submit@debbugs.gnu.org; Wed, 30 Oct 2024 19:59:09 -0400 Original-Received: from mail-ej1-f42.google.com ([209.85.218.42]:57487) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6Iae-0006W7-3L for 73863@debbugs.gnu.org; Wed, 30 Oct 2024 19:59:07 -0400 Original-Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-a9aa8895facso53681466b.2 for <73863@debbugs.gnu.org>; Wed, 30 Oct 2024 16:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730332678; x=1730937478; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=t8xUTrVgUR/kjFVmQC9nELqdlUrfWAL0IM12qvVLWGw=; b=T+2MzIeHp++2HVc8QRuABPenv4JGPD/xXHcBtrQuMXiJG39ofgHfDBumgtvnWB0CVG w6SsdoNPpyVItMx/Ed7PDOwymAuRKHgapQR+jC23mIsxHjrW0QUNWKfLjWgN/dUhCAMC f+IHK7g2C4K0OdNBe9cXGcVzmD5Loo3n/hkSI5DvpGTZOuEctJyEn+UZWiV2odnvWkkz ms3D+EUczH0RwTXUUaVRKNTqAUrGPebpBszirxtk4GdkGbbEBtekbZBI8QGELpHXHdLK qgCsruFRLIFxyq3qNhnvqBQF5He5Rr/N9IDgssSqsmulsTD+eWEKOmhr+GcWi1KREtM1 H1uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730332678; x=1730937478; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=t8xUTrVgUR/kjFVmQC9nELqdlUrfWAL0IM12qvVLWGw=; b=e5XIB5YBZr7z4/6AxOc4uoN4Tb+CViGzHdhsF2qlXPhl8g3mf0jAqkj86orvR8tdb7 bGfYhT829q4MP1ynUD/7VDX2yl4cuuNNOG2prQushNq7em6Gxwv4eyg6JTn02rK+RAo+ cQj+eyCfNA4rbDbi7HCt5A9DHrVtD99+yDGu1IPmZt7brh78LvPozDEZaCyVlZ+OOVtf yYz7M4ZKg4IwuCiWbA/JefEhSaXRJh2WKvl/M8ldqrCQF4v47cX2BiOcHMmJFAYE+N61 bHpRl//A0j153k/A53YKH2CqA/1ZRT5BvlujyCnK5lBNm5vDjif14bTT35y3HhBXyOWi NNsw== X-Forwarded-Encrypted: i=1; AJvYcCX2xrULA2q2cgiHr9obEKhuAJh+eaTM86aWO+kcMqqDtisCxMExqOSG4K/fm2OZW9f0X/1oVQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwT57oem7v+CU3fCbUeaITPISXjnM736R+CArsNHBLCIpGM8RIc MxA+Lv5G/ofrlWy44r8uDYlTHHJPVcVXwZdOCN3itJCGJ1PyLEP7o6GPcn4m0R3yaZgsaCljSuW sM79F35tcIwX9DcMtvDxILQMucHZ0BgT3cW0= X-Google-Smtp-Source: AGHT+IHNOHdkOY++dqQqigDBjNgTunrC5NlUBp5Ar55RgUaPecKGPoVhpLRIqaERlrTIQO87ldHN8AqierUZPyX9z9U= X-Received: by 2002:a17:906:730f:b0:a9a:1565:1051 with SMTP id a640c23a62f3a-a9de5d6e1fdmr1696017966b.10.1730332677585; Wed, 30 Oct 2024 16:57:57 -0700 (PDT) In-Reply-To: <865xpdak64.fsf@gnu.org> 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:294587 Archived-At: --0000000000009742a60625ba7842 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't use neovim but from what I have seen from screenshots, the diagnostics are truncated if they are larger than the window. Maybe there could be a way to have diagnostics truncated by default and only show the full diagnostics when the cursor is in the error line. But I'm not sure how that would work. For myself, I'll use sideline (https://github.com/emacs-sideline/sideline) instead of flymake-show-diagnostics-at-end-of-line. After thinking about it, I actually prefer to only view diagnostics for the current line (which is what sideline can do) On Sun, Oct 27, 2024 at 11:56=E2=80=AFAM Eli Zaretskii wrote= : > Ping! > > > Cc: 73863@debbugs.gnu.org, romain.ouabdelkader@gmail.com > > Date: Sun, 20 Oct 2024 14:22:24 +0300 > > From: Eli Zaretskii > > > > > From: Jo=C3=A3o T=C3=A1vora > > > Date: Sun, 20 Oct 2024 10:28:50 +0100 > > > Cc: Romain Ouabdelkader , > 73863@debbugs.gnu.org > > > > > > Flymake queries should be directed to Spencer Baugh > > > > Sorry, I keep forgetting that. > > > > > But if this fixes the user's problem and doesn't hurt anyone who does > > > have wide enough windows and on top of that sufficient testing is don= e, > > > I don't object to this solution. I don't know what that problem is. > Does > > > the user want their cursor to show at the end of the intangible > overlay? > > > If so, that's odd: I designed this feature to be as little intrusive > as possible > > > i.e. so that turning it on has no other effect than some text appeari= ng > > > at the end of line -- and only at the end of line. If there is littl= e > space, I > > > would say the right thing to do is to truncate, not wrap to the next > line > > > > When the diagnostic overlay wraps to the next screen line, it is > > strange to see the cursor at the beginning of the diagnostic after > > C-n, since users generally expect C-n to move to the next screen line. > > > > But if we decide that the current behavior is more reasonable, and > > this is just a matter of users getting used to it, I don't mind > > leaving the current behavior alone. > > > > > To try and answer your question, I don't think it is used by other > Flymake > > > parts (the function name hints at it: flymake--eol- means "end of > line"). > > > However, I advise to give it testing (with multiple diagnostics on on= e > > > line, for example). I remember trying many variations on these things > > > and each had its drawbacks. But possibly (probably?) I didn't test > > > this one. Anyway, do test this out with other flymake eol users and > > > consider the impact to users with wide enough windows: if there's no > > > impact I don't see why this wouldn't be acceptable. But that is for > > > Spencer or you to decide. > > > > Thanks. > > > > Spencer, what say you? > > > > > > > > > --0000000000009742a60625ba7842 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't use neovim but from what I have seen from scre= enshots, the diagnostics are truncated if they are larger than the window.<= div>
Maybe there could be a way to have diagnostics truncated = by default and only show the full diagnostics when the cursor is in the err= or=C2=A0line. But I'm not sure how that would=C2=A0work.

=
For myself, I'll use sideline (https://github.com/emacs-sideline/sideline) i= nstead of flymake-show-diagnostics-at-end-of-line.=C2=A0
Af= ter thinking about it, I actually prefer to only view diagnostics for the c= urrent line (which is what sideline can do)

On Sun, Oct 27, 2024= at 11:56=E2=80=AFAM Eli Zaretskii <eliz= @gnu.org> wrote:
Ping!

> Cc: 73863@d= ebbugs.gnu.org, romain.ouabdelkader@gmail.com
> Date: Sun, 20 Oct 2024 14:22:24 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
> > Date: Sun, 20 Oct 2024 10:28:50 +0100
> > Cc: Romain Ouabdelkader <romain.ouabdelkader@gmail.com>, 73863@debbugs.gnu.org<= /a>
> >
> > Flymake queries should be directed to Spencer Baugh
>
> Sorry, I keep forgetting that.
>
> > But if this fixes the user's problem and doesn't hurt any= one who does
> > have wide enough windows and on top of that sufficient testing is= done,
> > I don't object to this solution.=C2=A0 I don't know what = that problem is.=C2=A0 Does
> > the user want their cursor to show at the end of the intangible o= verlay?
> > If so, that's odd: I designed this feature to be as little in= trusive as possible
> > i.e. so that turning it on has no other effect than some text app= earing
> > at the end of line -- and only at the end of line.=C2=A0 If there= is little space, I
> > would say the right thing to do is to truncate, not wrap to the n= ext line
>
> When the diagnostic overlay wraps to the next screen line, it is
> strange to see the cursor at the beginning of the diagnostic after
> C-n, since users generally expect C-n to move to the next screen line.=
>
> But if we decide that the current behavior is more reasonable, and
> this is just a matter of users getting used to it, I don't mind > leaving the current behavior alone.
>
> > To try and answer your question,=C2=A0 I don't think it is us= ed by other Flymake
> > parts (the function name hints at it: flymake--eol- means "e= nd of line").
> > However, I advise to give it testing (with multiple diagnostics o= n one
> > line, for example). I remember trying many variations on these th= ings
> > and each had its drawbacks.=C2=A0 But possibly (probably?) I didn= 't test
> > this one.=C2=A0 Anyway, do test this out with other flymake eol u= sers and
> > consider the impact to users with wide enough windows: if there&#= 39;s no
> > impact I don't see why this wouldn't be acceptable. But t= hat is for
> > Spencer or you to decide.
>
> Thanks.
>
> Spencer, what say you?
>
>
>
>
--0000000000009742a60625ba7842--