From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#57433: Emacs no longer moves point into visible port of the buffer Date: Sat, 27 Aug 2022 18:12:49 +0200 Message-ID: References: <83y1vayqrm.fsf@gnu.org> <83v8qeypm5.fsf@gnu.org> <83sfliyonr.fsf@gnu.org> <83pmgmymdw.fsf@gnu.org> <83h71xznnn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000060b5405e73b4e40" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36985"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , 57433-done@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 27 18:14:10 2022 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 1oRyRm-0009T7-Dt for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Aug 2022 18:14:10 +0200 Original-Received: from localhost ([::1]:59026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oRyRk-00016R-Su for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Aug 2022 12:14:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43902) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oRyRe-00015w-BT for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 12:14:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38923) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oRyRe-0003VV-2W for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 12:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oRyRd-0004An-P4 for bug-gnu-emacs@gnu.org; Sat, 27 Aug 2022 12:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Aug 2022 16:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57433 X-GNU-PR-Package: emacs Original-Received: via spool by 57433-done@debbugs.gnu.org id=D57433.166161679215965 (code D ref 57433); Sat, 27 Aug 2022 16:14:01 +0000 Original-Received: (at 57433-done) by debbugs.gnu.org; 27 Aug 2022 16:13:12 +0000 Original-Received: from localhost ([127.0.0.1]:56902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRyQp-00049Q-Fq for submit@debbugs.gnu.org; Sat, 27 Aug 2022 12:13:12 -0400 Original-Received: from mail-ej1-f48.google.com ([209.85.218.48]:42807) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRyQm-00049B-HX for 57433-done@debbugs.gnu.org; Sat, 27 Aug 2022 12:13:09 -0400 Original-Received: by mail-ej1-f48.google.com with SMTP id p16so5052680ejb.9 for <57433-done@debbugs.gnu.org>; Sat, 27 Aug 2022 09:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=qypG3DXy/4nYrG4HF8+MwJ+b/zh7VZHhJOWalZ5Ivl0=; b=VHlkrR4XITeNnGg6RL8Kb1QPvLZbBGK0CXry2NX3r15qRz4GCR4zjAyHocJiMjkBgX jbiOsQ6Tw5EmPGVYc5yYjJLK7Yg6i3yqagUd0HZ9P5ttuUG5GemUaf7J171SSw3Ga1g+ gTykOwHEq2jUHgMaz7QFSMNToItf+MyVOnKin2L/JAOAlxcOLF/m6P4HUvBIe2ZwCxS5 ILr7kkWa9tNCIKtgqXaG3uDx7+FaIMcQnV7EduwxcChY9XFwp2RkrUGoNqf0o2I4Yhrs qtCMUYnBpDxUJTvysoIdTTLvWotqRqXIOzyLWeeTS4cIcOtgpwjeZpipTVc6NZugSpB+ WmPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=qypG3DXy/4nYrG4HF8+MwJ+b/zh7VZHhJOWalZ5Ivl0=; b=nMUwAFNW9r2CwglDmHKE6Zr1F0KaWis76ro0dK0xGS5/ncOcJq9045Vw4j1qgvlLhg Xan9IqwlhiPWRQg/4oIItJvi9bS+BQOz++ePfte+/FxJmE1GVCX2whkxzgQwaKG6KdaC Bxb25egvgDs4b81uyE8vinFEVLiyrppImt67PK+fyFZNumTUz9RIEa9MQJWQEyhnykrb 17Qdn09zYbK0d1qY8bcwGOKOb5YanUhKne6LWtq6vMOPMx0kP8a8gHeR8EQCl/3YtVZU CxczE5bR7W3R37y/CVMGYmvhwt0nAQOO2iRweCY3xfpY/Dj5RQCxS5lk9k3oJ9Y/0MnS HRqA== X-Gm-Message-State: ACgBeo0t4K7uD+xs98kaQZUEsvgmsYSXg/+Egv0wpan4hJRtyuz6msFb 2SrOaa6IancRoDqQRI5XzXhsLPAoFH68YBFHwA== X-Google-Smtp-Source: AA6agR4YJwvtfqcAWwVZeZI7kPt1F7oPtJsumuIZQsDhc8kiLRcWQN/ErZn4jIIau/cbYzVfQgu1XDd2qPANIjPXG+c= X-Received: by 2002:a17:907:284a:b0:730:a1f1:38b5 with SMTP id el10-20020a170907284a00b00730a1f138b5mr8093845ejc.732.1661616781657; Sat, 27 Aug 2022 09:13:01 -0700 (PDT) In-Reply-To: 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" Xref: news.gmane.io gmane.emacs.bugs:240951 Archived-At: --000000000000060b5405e73b4e40 Content-Type: text/plain; charset="UTF-8" Actually, disregard that. It appears to be a Magit bug. If I switch the buffer to any other mode, everything behaves as expected. Paul On Sat, 27 Aug 2022 at 18:06, Paul Pogonyshev wrote: > > The "reason" is largely a side-effect of the implementation, I > > suspect. > > Would it then not be a good idea to improve it (not as part of this bug, > of course)? E.g. currently the behavior is like below. > > Setup: Magit buffer with staged files, at least two. It looks like this: > > Staged changes (N) > modified file1 > [invisible diff of file1] > modified file2 > [invisible diff of file2] > > so essentially I, as a user, only see this in UI: > > Staged changes (N) > modified file1 > modified file2 > > Now, I put the point at the beginning of the third line ([^] is the point): > > Staged changes (N) > modified file1 > [^]modified file2 > > I press C-b, expecting that the point is moved to the end of the > previous line that I see. But it is not moved there, this is the result: > > Staged changes (N) > modified file1 > [^]modified file2 > > In reality, the point is in the invisible (to me, as the user) diff for > file1. > If I press C-b again, only now point is moved like I expected it to be > moved the last time: > > Staged changes (N) > modified file1[^] > modified file2 > > So, the presence of invisible text between lines 2 and 3 changes the > way C-b behaves and breaks my (as a user of Emacs) expectations, > disrupting established editing flow. I'd say that the invisible text > should count as implementation details and shouldn't affect user- > visible results at all. > > What do you think? > > Paul > > > On Sat, 27 Aug 2022 at 17:55, Eli Zaretskii wrote: > >> > From: Paul Pogonyshev >> > Date: Sat, 27 Aug 2022 17:47:32 +0200 >> > Cc: Eli Zaretskii , 57433@debbugs.gnu.org >> > >> > > Strange. Could you please double-check that you have commit >> > > a2d62456a7b8da27fb9b64f71b6ce588f2d73287 in your worktree? >> > >> > I have rebuilt Emacs and now it works. I previously tried with applying >> > the patch from "In that case, can you see if the patch below solves the >> > original issue with Magit?" locally, but apparently did something wrong. >> > >> > So yes, it works for me now, sorry. >> >> No need to be sorry, thanks for testing the fix. I'm therefore >> closing the bug. >> >> > > I think you are reading too much into what that text says. It says >> > > that point moves to the edge of such a sequence, and that is what >> > > happens here. No more, no less. >> > >> > Yeah, I see now that if you move with C-b, the point disappears within >> > the diff for the previous file, even with Emacs 28, and then Magit >> > misbehaves. To be honest, I'm not sure if that is useful (or maybe there >> > is some reason for moving "to the edge" rather than outside an >> > invisible sequence), but that's certainly not a regression in Emacs. >> >> The "reason" is largely a side-effect of the implementation, I >> suspect. >> > --000000000000060b5405e73b4e40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually, disregard that. It appears to be a Magit bug. If= I switch the buffer
to any other mode, everything behaves as expected.=

Paul

On Sat, 27 Aug 2022 at 18:06, Paul Pogo= nyshev <pogonyshev@gmail.com= > wrote:
> The "reason" is largely a side-effect of the im= plementation, I
> suspect.

Would it then not b= e a good idea to improve it (not as part of this bug,
of course)?= E.g. currently the behavior is like below.

Setup:= Magit buffer with staged files, at least two. It looks like this:

Staged changes (N)
modified=C2=A0 =C2=A0 file1
[invisible diff of file1]
modified=C2=A0 =C2=A0 fil= e2
[invisible diff of file2]

so es= sentially I, as a user, only see this in UI:

= Staged changes (N)
modified=C2=A0 =C2=A0 file1
modified= =C2=A0 =C2=A0 file2

Now, I pu= t the point at the beginning of the third line ([^] is the point):

Staged changes (N)
modified=C2=A0 =C2=A0 fi= le1
[^]modified=C2=A0 =C2=A0 file2

I= press C-b, expecting that the point is moved to the end of the
p= revious line that I see. But it is not moved there, this is the result:

Staged changes (N)
modified=C2=A0 =C2= =A0 file1
[^]modified=C2=A0 =C2=A0 file2

=
In reality, the point is in the invisible (to me, as the user) d= iff for file1.
If I press C-b again, only now point is moved like= I expected it to be
moved the last time:

Staged changes (N)
modified=C2=A0 =C2=A0 file1[^]
modified=C2=A0 =C2=A0 file2

So, the pr= esence of invisible text between lines 2 and 3 changes the
way C-= b behaves and breaks my (as a user of Emacs) expectations,
disrup= ting established editing flow. I'd say that the invisible text
should count as implementation details and shouldn't affect user-
visible results at all.

What do you think?<= /div>

Paul

On Sat, = 27 Aug 2022 at 17:55, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Paul Pogonyshev <pogonyshev@gmail.com>
> Date: Sat, 27 Aug 2022 17:47:32 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 57433@debbugs.gnu.org
>
> > Strange.=C2=A0 Could you please double-check that you have commit=
> > a2d62456a7b8da27fb9b64f71b6ce588f2d73287 in your worktree?
>
> I have rebuilt Emacs and now it works. I previously tried with applyin= g
> the patch from "In that case, can you see if the patch below solv= es the
> original issue with Magit?" locally, but apparently did something= wrong.
>
> So yes, it works for me now, sorry.

No need to be sorry, thanks for testing the fix.=C2=A0 I'm therefore closing the bug.

> > I think you are reading too much into what that text says.=C2=A0 = It says
> > that point moves to the edge of such a sequence, and that is what=
> > happens here.=C2=A0 No more, no less.
>
> Yeah, I see now that if you move with C-b, the point disappears within=
> the diff for the previous file, even with Emacs 28, and then Magit
> misbehaves. To be honest, I'm not sure if that is useful (or maybe= there
> is some reason for moving "to the edge" rather than outside = an
> invisible sequence), but that's certainly not a regression in Emac= s.

The "reason" is largely a side-effect of the implementation, I suspect.
--000000000000060b5405e73b4e40--