GNU bug report logs - #57433
Emacs no longer moves point into visible port of the buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57433 in the body.
You can then email your comments to 57433 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs no longer moves point into visible port of the buffer
Date: Fri, 26 Aug 2022 18:32:14 +0200

[Message part 1 (text/plain, inline)]

Git commit 233c91d32a. Has been broken at least for a few days: my previous
build also exhibited this.

No idea how to create a short test in Elisp.

From user point of view: open a Magit buffer in a directory with at least
two locally modified and uncommitted files. The buffer shows sth. like this:

...
Staged changes (N)
modified   file1
modified   file2
...

Move the point with C-n to the line with `file2'. Press TAB. Magit section
for the file is not opened. Use `M-x describe-char'. From the resulting
buffer you can say that the point is actually on an invisible char '@',
i.e. start of (hidden) diff for the first file.

It may be necessary to restart Emacs if you have used Magit in this
directory previously.

This used to work fine (i.e. point was never on an invisible character)
both in Emacs 28 and earlier snapshots of `master'.

Paul

[Message part 2 (text/html, inline)]

Message #8 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 08:55:49 +0200

Paul Pogonyshev <pogonyshev <at> gmail.com> writes:

> Git commit 233c91d32a. Has been broken at least for a few days: my previous build also exhibited this.
>
> No idea how to create a short test in Elisp.
>
> From user point of view: open a Magit buffer in a directory with at least two locally modified and uncommitted files. The buffer shows sth. like
> this:
>
> ...
> Staged changes (N)
> modified   file1
> modified   file2
> ...
>
> Move the point with C-n to the line with `file2'. Press TAB. Magit section for the file is not opened. Use `M-x describe-char'. From the resulting
> buffer you can say that the point is actually on an invisible char '@', i.e. start of (hidden) diff for the first file.
>
> It may be necessary to restart Emacs if you have used Magit in this directory previously.
>
> This used to work fine (i.e. point was never on an invisible character) both in Emacs 28 and earlier snapshots of `master'.
>
> Paul

I can reproduce this.  Bisecting.

Message #11 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 10:08:26 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

a71c05b44de74fe16691f680df34c4534992e472 is the first bad commit
commit a71c05b44de74fe16691f680df34c4534992e472
Author: Eli Zaretskii <eliz <at> gnu.org>
Date:   Sun Aug 14 15:47:59 2022 +0300
    Further speedups of redisplay of long and truncated lines
    
    * src/xdisp.c (mode_line_update_needed, redisplay_window)
    (decode_mode_spec): Don't avoid calling current_column, as it is
    now fast enough.
    (redisplay_window) <optional_new_start>: Don't call 'move_it_to'
    if its result will not be used.
    (Flong_line_optimizations_p): New primitive.
    * src/indent.c (Fcurrent_column): Doc fix.
    (current_column, scan_for_column): When in a buffer with long
    and/or truncated lines, quickly return an approximate value.
    * src/window.c (Frecenter): Use the old text-mode code when the
    buffer has very long lines.
    
    * lisp/simple.el (line-move): Avoid costly calls to
    'line-move-partial' and 'line-move-visual' when lines are
    truncated and/or very long.
    (move-beginning-of-line): Call 'line-beginning-position' instead
    of the slower 'skip-chars-backward'.
    
    * etc/NEWS: Announce 'long-line-optimizations-p'.
 etc/NEWS       |  3 +++
 lisp/simple.el | 31 ++++++++++++++++++++---
 src/indent.c   | 60 ++++++++++++++++++++++++++++++++++++++------
 src/window.c   |  9 ++++---
 src/xdisp.c    | 79 +++++++++++++++++++++++++++++-----------------------------
 5 files changed, 129 insertions(+), 53 deletions(-)


I will look at the changes in simple.el soon if no-one beats me.

Message #14 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 10:53:37 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> a71c05b44de74fe16691f680df34c4534992e472 is the first bad commit
>
> I will look at the changes in simple.el soon if no-one beats me.

Hm, I must admit that I don't understand the change in line-move, or
better said the context in which it was made.  So if I fix this I
probably break some optimization.

I have a simple recipe now, though.

emacs -Q

Insert and eval this function:

(defun hansi ()
  (insert "line 1\n")
  (insert (propertize "+invisible 1\ninvisible2-\n" 'invisible t))
  (insert "line 2\n"))

M-: (hansi) RET
C-p
C-x =
=>
Char: + (43, #o53, #x2b) point=330 of 365 (90%) column=0

That's something for Eli, I'd say.

Message #17 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 57433 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 12:33:49 +0300

> Cc: 57433 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Sat, 27 Aug 2022 10:53:37 +0200
> 
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
> > a71c05b44de74fe16691f680df34c4534992e472 is the first bad commit
> >
> > I will look at the changes in simple.el soon if no-one beats me.
> 
> Hm, I must admit that I don't understand the change in line-move, or
> better said the context in which it was made.  So if I fix this I
> probably break some optimization.

The changes in line-move should only affect buffers with very long
lines.

> I have a simple recipe now, though.
> 
> emacs -Q
> 
> Insert and eval this function:
> 
> (defun hansi ()
>   (insert "line 1\n")
>   (insert (propertize "+invisible 1\ninvisible2-\n" 'invisible t))
>   (insert "line 2\n"))
> 
> M-: (hansi) RET
> C-p
> C-x =
> =>
> Char: + (43, #o53, #x2b) point=330 of 365 (90%) column=0

Why is that a problem?  I get the same result on the emacs-28 branch,
where the changes in this commit were not installed.  And the OP said
the problem is new on master.

Message #20 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 12:47:19 +0300

> From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> Date: Fri, 26 Aug 2022 18:32:14 +0200
> 
> Git commit 233c91d32a. Has been broken at least for a few days: my previous build also exhibited this.
> 
> No idea how to create a short test in Elisp.
> 
> From user point of view: open a Magit buffer in a directory with at least two locally modified and uncommitted
> files. The buffer shows sth. like this:
> 
> ...
> Staged changes (N)
> modified   file1
> modified   file2
> ...
> 
> Move the point with C-n to the line with `file2'. Press TAB. Magit section for the file is not opened. Use `M-x
> describe-char'. From the resulting buffer you can say that the point is actually on an invisible char '@', i.e.
> start of (hidden) diff for the first file.

Can you tell what is the actual buffer text and where are the
invisible text properties on it?

Message #23 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57433 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 11:55:12 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Char: + (43, #o53, #x2b) point=330 of 365 (90%) column=0
>
> Why is that a problem?  I get the same result on the emacs-28 branch,
> where the changes in this commit were not installed.  And the OP said
> the problem is new on master.

Then it's probably not the right recipe, sorry.

Message #26 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: gerd.moellmann <at> gmail.com
Cc: 57433 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 12:58:42 +0300

> Cc: 57433 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
> Date: Sat, 27 Aug 2022 12:33:49 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Cc: 57433 <at> debbugs.gnu.org
> > From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> > Date: Sat, 27 Aug 2022 10:53:37 +0200
> > 
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> > 
> > > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> > >
> > > a71c05b44de74fe16691f680df34c4534992e472 is the first bad commit
> > >
> > > I will look at the changes in simple.el soon if no-one beats me.
> > 
> > Hm, I must admit that I don't understand the change in line-move, or
> > better said the context in which it was made.  So if I fix this I
> > probably break some optimization.
> 
> The changes in line-move should only affect buffers with very long
> lines.

Does Magit turn on truncate-lines in the affected buffer, or cause
them be truncated due to partial-width windows?  If it does, I might
have an idea what could cause the OP's problem.

Message #29 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57433 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 12:02:32 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Does Magit turn on truncate-lines in the affected buffer, or cause
> them be truncated due to partial-width windows?  If it does, I might
> have an idea what could cause the OP's problem.

Yes, truncate-lines it t.

Message #32 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 57433 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 13:19:20 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 57433 <at> debbugs.gnu.org,  pogonyshev <at> gmail.com
> Date: Sat, 27 Aug 2022 12:02:32 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Does Magit turn on truncate-lines in the affected buffer, or cause
> > them be truncated due to partial-width windows?  If it does, I might
> > have an idea what could cause the OP's problem.
> 
> Yes, truncate-lines it t.

In that case, can you see if the patch below solves the original issue
with Magit?

diff --git a/lisp/simple.el b/lisp/simple.el
index ee765c8..d18d54c 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -7717,13 +7717,15 @@ line-move
 	       (not goal-column)
                ;; Lines aren't truncated.
                (not
-                (or truncate-lines
-                    (and (integerp truncate-partial-width-windows)
-                         (< (window-width)
-                            truncate-partial-width-windows))
-                    (and truncate-partial-width-windows
-                         (not (integerp truncate-partial-width-windows))
-                         (not (window-full-width-p)))))
+                (and
+                 (or truncate-lines
+                     (and (integerp truncate-partial-width-windows)
+                          (< (window-total-width)
+                             truncate-partial-width-windows))
+                     (and truncate-partial-width-windows
+                          (not (integerp truncate-partial-width-windows))
+                          (not (window-full-width-p))))
+                 (long-line-optimizations-p)))
 	       ;; When the text in the window is scrolled to the left,
 	       ;; display-based motion doesn't make sense (because each
 	       ;; logical line occupies exactly one screen line).

Message #35 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57433 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 12:43:18 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: 57433 <at> debbugs.gnu.org,  pogonyshev <at> gmail.com
>> Date: Sat, 27 Aug 2022 12:02:32 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Does Magit turn on truncate-lines in the affected buffer, or cause
>> > them be truncated due to partial-width windows?  If it does, I might
>> > have an idea what could cause the OP's problem.
>> 
>> Yes, truncate-lines it t.
>
> In that case, can you see if the patch below solves the original issue
> with Magit?

Works for me.  Thanks!

Message #38 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 57433 <at> debbugs.gnu.org, pogonyshev <at> gmail.com
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 14:08:27 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 57433 <at> debbugs.gnu.org,  pogonyshev <at> gmail.com
> Date: Sat, 27 Aug 2022 12:43:18 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> >> Cc: 57433 <at> debbugs.gnu.org,  pogonyshev <at> gmail.com
> >> Date: Sat, 27 Aug 2022 12:02:32 +0200
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> > Does Magit turn on truncate-lines in the affected buffer, or cause
> >> > them be truncated due to partial-width windows?  If it does, I might
> >> > have an idea what could cause the OP's problem.
> >> 
> >> Yes, truncate-lines it t.
> >
> > In that case, can you see if the patch below solves the original issue
> > with Magit?
> 
> Works for me.  Thanks!

Thanks, installed.

Paul, please see that your original problem is now solved.

(Btw, I think it's a subtle bug in Magit that it assumes cursor motion
will never end up on invisible text in such buffers.)

Message #41 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 16:07:49 +0200

[Message part 1 (text/plain, inline)]

> Paul, please see that your original problem is now solved.

No, don't see any change in behavior.

> (Btw, I think it's a subtle bug in Magit that it assumes cursor motion
> will never end up on invisible text in such buffers.)

I don't think it is a bug. It is explicitly promised in Elisp manual as I
see:

> 22.6 Adjusting Point After Commands
> ===================================
>
> Emacs cannot display the cursor when point is in the middle of a
> sequence of text that has the ‘display’ or ‘composition’ property, or is
> *invisible*.  Therefore, after a command finishes and returns to the
> command loop, if point is within such a sequence, the command loop
> normally moves point to the edge of the sequence, making this sequence
> effectively intangible.

That's why, btw, I couldn't create a testcase: I don't know how to emulate
command loop.

Paul

On Sat, 27 Aug 2022 at 13:08, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> > Cc: 57433 <at> debbugs.gnu.org,  pogonyshev <at> gmail.com
> > Date: Sat, 27 Aug 2022 12:43:18 +0200
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> > >> Cc: 57433 <at> debbugs.gnu.org,  pogonyshev <at> gmail.com
> > >> Date: Sat, 27 Aug 2022 12:02:32 +0200
> > >>
> > >> Eli Zaretskii <eliz <at> gnu.org> writes:
> > >>
> > >> > Does Magit turn on truncate-lines in the affected buffer, or cause
> > >> > them be truncated due to partial-width windows?  If it does, I might
> > >> > have an idea what could cause the OP's problem.
> > >>
> > >> Yes, truncate-lines it t.
> > >
> > > In that case, can you see if the patch below solves the original issue
> > > with Magit?
> >
> > Works for me.  Thanks!
>
> Thanks, installed.
>
> Paul, please see that your original problem is now solved.
>
> (Btw, I think it's a subtle bug in Magit that it assumes cursor motion
> will never end up on invisible text in such buffers.)
>

[Message part 2 (text/html, inline)]

Message #44 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: 57433 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 16:28:33 +0200

Paul Pogonyshev <pogonyshev <at> gmail.com> writes:

>> Paul, please see that your original problem is now solved.
>
> No, don't see any change in behavior.

Strange.  Could you please double-check that you have commit
a2d62456a7b8da27fb9b64f71b6ce588f2d73287 in your worktree?

Message #47 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 18:13:04 +0300

> From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> Date: Sat, 27 Aug 2022 16:07:49 +0200
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 
> 	57433 <at> debbugs.gnu.org
> 
> > Paul, please see that your original problem is now solved.
> 
> No, don't see any change in behavior.

Then I guess what you see is a separate and different problem.

> > (Btw, I think it's a subtle bug in Magit that it assumes cursor motion
> > will never end up on invisible text in such buffers.)
> 
> I don't think it is a bug. It is explicitly promised in Elisp manual as I see:
> 
> > 22.6 Adjusting Point After Commands
> > ===================================
> > 
> > Emacs cannot display the cursor when point is in the middle of a
> > sequence of text that has the ‘display’ or ‘composition’ property, or is
> > invisible.  Therefore, after a command finishes and returns to the
> > command loop, if point is within such a sequence, the command loop
> > normally moves point to the edge of the sequence, making this sequence
> > effectively intangible.

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.

> That's why, btw, I couldn't create a testcase: I don't know how to emulate
> command loop.

Exactly.

Message #50 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 57433 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 17:47:32 +0200

[Message part 1 (text/plain, inline)]

> 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.

> 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.

Paul


On Sat, 27 Aug 2022 at 16:28, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:

> Paul Pogonyshev <pogonyshev <at> gmail.com> writes:
>
> >> Paul, please see that your original problem is now solved.
> >
> > No, don't see any change in behavior.
>
> Strange.  Could you please double-check that you have commit
> a2d62456a7b8da27fb9b64f71b6ce588f2d73287 in your worktree?
>

[Message part 2 (text/html, inline)]

Message #55 received at 57433-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 57433-done <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 18:55:40 +0300

> From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> Date: Sat, 27 Aug 2022 17:47:32 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 57433 <at> 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.

Message #58 received at 57433-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 57433-done <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 18:06:59 +0200

[Message part 1 (text/plain, inline)]

> 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 <eliz <at> gnu.org> wrote:

> > From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> > Date: Sat, 27 Aug 2022 17:47:32 +0200
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 57433 <at> 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.
>

[Message part 2 (text/html, inline)]

Message #61 received at 57433-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 57433-done <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 18:12:49 +0200

[Message part 1 (text/plain, inline)]

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 <pogonyshev <at> gmail.com> 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 <eliz <at> gnu.org> wrote:
>
>> > From: Paul Pogonyshev <pogonyshev <at> gmail.com>
>> > Date: Sat, 27 Aug 2022 17:47:32 +0200
>> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 57433 <at> 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.
>>
>

[Message part 2 (text/html, inline)]

Message #64 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 19:25:42 +0300

> From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> Date: Sat, 27 Aug 2022 18:06:59 +0200
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 
> 	57433-done <at> debbugs.gnu.org
> 
> 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

I cannot reproduce this, if I try to simulate it by having those 4
lines with two lines invisible.  So I think there's something else at
work here.  If you can show a simple recipe that doesn't involve
Magit, I can look into what happens there.  (And it probably warrants
a separate bug report.)

What I did was to have this text:

  modified    file1
  [invisible diff of file1]
  modified    file2
  [invisible diff of file2]

(without the indentation) in a buffer, and then I manually put the
invisible text property on the 2nd and the 4th lines.  Then I moved
the cursor with C-b from the beginning of "modified file2", and the
cursor was displayed at the end of the previous visible line, the one
which says "modified file1".

> 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?

It works for me the way you expect it to work, so I'm not yet sure
what's going on in the Magit buffer.

Message #67 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 19:29:12 +0300

> From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> Date: Sat, 27 Aug 2022 18:12:49 +0200
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 
> 	57433-done <at> debbugs.gnu.org
> 
> Actually, disregard that. It appears to be a Magit bug. If I switch the buffer
> to any other mode, everything behaves as expected.

Right.  I suspect that Magit puts something else there, not just the
invisible property.  What does describe-text-properties say at that
point?

Message #70 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 18:32:15 +0200

[Message part 1 (text/plain, inline)]

> Now, I put the point at the beginning of the third line ([^] is the
point):

Text content at position 32867:

There is an overlay here:
 From 32867 to 32901
  evaporate            t
  font-lock-face       magit-diff-file-heading-highlight

There are text properties here:
  font-lock-face       magit-diff-file-heading
  keymap               [Show]
  magit-section        [Show]

> 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

Text content at position 29881:

There is an overlay here:
 From 29881 to 32867
  evaporate            t
  invisible            t

There are text properties here:
  font-lock-face       magit-diff-hunk-heading
  keymap               [Show]
  magit-section        [Show]

> If I press C-b again, only now point is moved

Text content at position 29880:

There is an overlay here:
 From 29858 to 29881
  evaporate            t
  font-lock-face       magit-diff-file-heading-highlight

There are text properties here:
  keymap               [Show]
  magit-section        [Show]

Paul

On Sat, 27 Aug 2022 at 18:28, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> > Date: Sat, 27 Aug 2022 18:12:49 +0200
> > Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
> >       57433-done <at> debbugs.gnu.org
> >
> > Actually, disregard that. It appears to be a Magit bug. If I switch the
> buffer
> > to any other mode, everything behaves as expected.
>
> Right.  I suspect that Magit puts something else there, not just the
> invisible property.  What does describe-text-properties say at that
> point?
>

[Message part 2 (text/html, inline)]

Message #73 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 18:37:22 +0200

[Message part 1 (text/plain, inline)]

Also, the value of `magit-section' is different all three times, if that's
important.

Paul

On Sat, 27 Aug 2022 at 18:32, Paul Pogonyshev <pogonyshev <at> gmail.com> wrote:

> > Now, I put the point at the beginning of the third line ([^] is the
> point):
>
> Text content at position 32867:
>
> There is an overlay here:
>  From 32867 to 32901
>   evaporate            t
>   font-lock-face       magit-diff-file-heading-highlight
>
> There are text properties here:
>   font-lock-face       magit-diff-file-heading
>   keymap               [Show]
>   magit-section        [Show]
>
> > 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
>
> Text content at position 29881:
>
> There is an overlay here:
>  From 29881 to 32867
>   evaporate            t
>   invisible            t
>
> There are text properties here:
>   font-lock-face       magit-diff-hunk-heading
>   keymap               [Show]
>   magit-section        [Show]
>
> > If I press C-b again, only now point is moved
>
> Text content at position 29880:
>
> There is an overlay here:
>  From 29858 to 29881
>   evaporate            t
>   font-lock-face       magit-diff-file-heading-highlight
>
> There are text properties here:
>   keymap               [Show]
>   magit-section        [Show]
>
> Paul
>
> On Sat, 27 Aug 2022 at 18:28, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Paul Pogonyshev <pogonyshev <at> gmail.com>
>> > Date: Sat, 27 Aug 2022 18:12:49 +0200
>> > Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>> >       57433-done <at> debbugs.gnu.org
>> >
>> > Actually, disregard that. It appears to be a Magit bug. If I switch the
>> buffer
>> > to any other mode, everything behaves as expected.
>>
>> Right.  I suspect that Magit puts something else there, not just the
>> invisible property.  What does describe-text-properties say at that
>> point?
>>
>

[Message part 2 (text/html, inline)]

Message #76 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 19:56:48 +0300

> From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> Date: Sat, 27 Aug 2022 18:32:15 +0200
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 
> 	57433 <at> debbugs.gnu.org
> 
> > Now, I put the point at the beginning of the third line ([^] is the point):
> 
> Text content at position 32867:
> 
> There is an overlay here:
>  From 32867 to 32901
>   evaporate            t
>   font-lock-face       magit-diff-file-heading-highlight
> 
> There are text properties here:
>   font-lock-face       magit-diff-file-heading
>   keymap               [Show]
>   magit-section        [Show]

Maybe the 'keymap' part?  Could it be that C-b has a binding in that
keymap?

Message #79 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 19:01:51 +0200

[Message part 1 (text/plain, inline)]

There is no mode binding (`C-h k C-b' returns `backward-char'). I don't know
how to read this (result of showing the keymap in `describe-text-properties'
buffer; at step 1:

(keymap keymap
        (3 keymap
           (5 . magit-diff-edit-hunk-commit)
           (20 . magit-diff-trace-definition))
        (67 . magit-commit-add-log)
        (38 . magit-do-async-shell-command)
        (117 . magit-unstage)
        (115 . magit-stage)
        (97 . magit-apply)
        (remap keymap
               (magit-revert-no-commit . magit-reverse)
               (magit-delete-thing . magit-discard)
               (magit-visit-thing . magit-diff-visit-file))
        (24 keymap
            (97 . magit-add-change-log-entry)
            (53 keymap
                (return . magit-diff-visit-file-other-frame))
            (52 keymap
                (97 . magit-add-change-log-entry-other-window)
                (return . magit-diff-visit-file-other-window)))
        (C-return . magit-diff-visit-worktree-file)
        (10 . magit-diff-visit-worktree-file))

At step 2:

(keymap
 (3 keymap
    (94 keymap
        (108 . magit-smerge-keep-lower)
        (98 . magit-smerge-keep-base)
        (117 . magit-smerge-keep-upper)
        (13 . magit-smerge-keep-current)))
 keymap
 (3 keymap
    (5 . magit-diff-edit-hunk-commit)
    (20 . magit-diff-trace-definition))
 (67 . magit-commit-add-log)
 (38 . magit-do-async-shell-command)
 (117 . magit-unstage)
 (115 . magit-stage)
 (97 . magit-apply)
 (remap keymap
        (magit-revert-no-commit . magit-reverse)
        (magit-delete-thing . magit-discard)
        (magit-visit-thing . magit-diff-visit-file))
 (24 keymap
     (97 . magit-add-change-log-entry)
     (53 keymap
         (return . magit-diff-visit-file-other-frame))
     (52 keymap
         (97 . magit-add-change-log-entry-other-window)
         (return . magit-diff-visit-file-other-window)))
 (C-return . magit-diff-visit-worktree-file)

Paul
 (10 . magit-diff-visit-worktree-file))

On Sat, 27 Aug 2022 at 18:56, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> > Date: Sat, 27 Aug 2022 18:32:15 +0200
> > Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
> >       57433 <at> debbugs.gnu.org
> >
> > > Now, I put the point at the beginning of the third line ([^] is the
> point):
> >
> > Text content at position 32867:
> >
> > There is an overlay here:
> >  From 32867 to 32901
> >   evaporate            t
> >   font-lock-face       magit-diff-file-heading-highlight
> >
> > There are text properties here:
> >   font-lock-face       magit-diff-file-heading
> >   keymap               [Show]
> >   magit-section        [Show]
>
> Maybe the 'keymap' part?  Could it be that C-b has a binding in that
> keymap?
>

[Message part 2 (text/html, inline)]

Message #82 received at 57433 <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 57433 <at> debbugs.gnu.org
Subject: Re: bug#57433: Emacs no longer moves point into visible port of the
 buffer
Date: Sat, 27 Aug 2022 19:11:33 +0200

[Message part 1 (text/plain, inline)]

By the way, here is a simple way to test Magit without installing it in your
Emacs. However, you will need Eldev (external relative to Emacs).

1. Install Eldev (https://github.com/doublep/eldev#installation)

2. Check out Magit sources, e.g. to `~/git/magit'

3. Run `$ cd ~/git/magit/*lisp*' (I don't know why they have this layout)

4. Create file `Eldev-local' with the following contents (since the
project doesn't use Eldev, you have to do this manually):

(setf eldev-project-main-file "magit.el")
(eldev-use-package-archive 'gnu-elpa)
(eldev-use-package-archive 'melpa)

5. Run e.g. like this: `$ eldev emacs --eval "(magit-status-setup-buffer
\"~/emacs\")" ',
assuming `~/emacs' is a Git checkout you work on.

Paul

On Sat, 27 Aug 2022 at 19:01, Paul Pogonyshev <pogonyshev <at> gmail.com> wrote:

> There is no mode binding (`C-h k C-b' returns `backward-char'). I don't
> know
> how to read this (result of showing the keymap in
> `describe-text-properties'
> buffer; at step 1:
>
> (keymap keymap
>         (3 keymap
>            (5 . magit-diff-edit-hunk-commit)
>            (20 . magit-diff-trace-definition))
>         (67 . magit-commit-add-log)
>         (38 . magit-do-async-shell-command)
>         (117 . magit-unstage)
>         (115 . magit-stage)
>         (97 . magit-apply)
>         (remap keymap
>                (magit-revert-no-commit . magit-reverse)
>                (magit-delete-thing . magit-discard)
>                (magit-visit-thing . magit-diff-visit-file))
>         (24 keymap
>             (97 . magit-add-change-log-entry)
>             (53 keymap
>                 (return . magit-diff-visit-file-other-frame))
>             (52 keymap
>                 (97 . magit-add-change-log-entry-other-window)
>                 (return . magit-diff-visit-file-other-window)))
>         (C-return . magit-diff-visit-worktree-file)
>         (10 . magit-diff-visit-worktree-file))
>
> At step 2:
>
> (keymap
>  (3 keymap
>     (94 keymap
>         (108 . magit-smerge-keep-lower)
>         (98 . magit-smerge-keep-base)
>         (117 . magit-smerge-keep-upper)
>         (13 . magit-smerge-keep-current)))
>  keymap
>  (3 keymap
>     (5 . magit-diff-edit-hunk-commit)
>     (20 . magit-diff-trace-definition))
>  (67 . magit-commit-add-log)
>  (38 . magit-do-async-shell-command)
>  (117 . magit-unstage)
>  (115 . magit-stage)
>  (97 . magit-apply)
>  (remap keymap
>         (magit-revert-no-commit . magit-reverse)
>         (magit-delete-thing . magit-discard)
>         (magit-visit-thing . magit-diff-visit-file))
>  (24 keymap
>      (97 . magit-add-change-log-entry)
>      (53 keymap
>          (return . magit-diff-visit-file-other-frame))
>      (52 keymap
>          (97 . magit-add-change-log-entry-other-window)
>          (return . magit-diff-visit-file-other-window)))
>  (C-return . magit-diff-visit-worktree-file)
>
> Paul
>  (10 . magit-diff-visit-worktree-file))
>
> On Sat, 27 Aug 2022 at 18:56, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Paul Pogonyshev <pogonyshev <at> gmail.com>
>> > Date: Sat, 27 Aug 2022 18:32:15 +0200
>> > Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>> >       57433 <at> debbugs.gnu.org
>> >
>> > > Now, I put the point at the beginning of the third line ([^] is the
>> point):
>> >
>> > Text content at position 32867:
>> >
>> > There is an overlay here:
>> >  From 32867 to 32901
>> >   evaporate            t
>> >   font-lock-face       magit-diff-file-heading-highlight
>> >
>> > There are text properties here:
>> >   font-lock-face       magit-diff-file-heading
>> >   keymap               [Show]
>> >   magit-section        [Show]
>>
>> Maybe the 'keymap' part?  Could it be that C-b has a binding in that
>> keymap?
>>
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.