GNU bug report logs -
#45319
28.0.50; Redisplay: `forward-char' moves backwards into invisible text
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sun, 20 Dec 2020 17:38:26 +0200
with message-id <83wnxcsd1p.fsf <at> gnu.org>
and subject line Re: bug#45319: 28.0.50; Redisplay: `forward-char' moves backwards into invisible text
has caused the debbugs.gnu.org bug report #45319,
regarding 28.0.50; Redisplay: `forward-char' moves backwards into invisible text
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
45319: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=45319
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
Hello,
I have found a strange problem I encountered in the Magit Log buffer,
but it is reproducible in any buffer in emacs -Q. CC'ing Jonas
Bernoulli, maintainer of Magit, for information.
I insert something like this into e.g. *scratch* (looks a bit like a
Magit log buffer):
[test.txt (text/plain, inline)]
11111
a
b
c
22222
x
y
z
33333
f
g
h
44444
i
j
k
[Message part 5 (text/plain, inline)]
Lets do this:
(add-hook 'post-command-hook (lambda () (message "%s" (point))))
to see the value of point when we move around in the buffer.
I want to hide lines that start with whitespace, so I do this:
(defvar my-magit-log-show-only-hash-lines-mode-keywords
`((,(rx (and bol space (* any) eol))
(0 (let ((beg (match-beginning 0))
(end (1+ (match-end 0))))
(add-text-properties beg end
(list 'invisible 'my-magit-log-show-only-hash-lines))
nil)))))
(define-minor-mode my-magit-log-show-only-hash-lines-mode
"..." nil nil nil
(if (not my-magit-log-show-only-hash-lines-mode)
(remove-from-invisibility-spec 'my-magit-log-show-only-hash-lines)
(font-lock-add-keywords nil my-magit-log-show-only-hash-lines-mode-keywords)
(add-to-invisibility-spec 'my-magit-log-show-only-hash-lines)))
Now enable that mode in the buffer and M-x font-lock-fontify-buffer.
When I now move around in the buffer with the arrow keys, it often
happens that when point is at the beginning of a visible line, and I hit
<right>, the echo area shows that point actually has moved backwards into
the invisible area somewhere before that line, but the cursor is placed
at the expected position. Further movement behaves as expected from the
drawn cursor position, just the value of `point' sometimes is
inconsistent, and that can cause trouble (like incorrect section
highlighting in the Magit Log buffer).
TIA,
Michael.
[Message part 6 (message/rfc822, inline)]
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 45319 <at> debbugs.gnu.org, jonas <at> bernoul.li
> Date: Sun, 20 Dec 2020 09:01:52 +0100
>
> I see now that that problem has been discussed in Bug#23079. If you
> think that everything is alright with my test case you might close this
> bug and probably merge with that one.
I closed this one. Merging them is too much of a hassle with
debbugs's unhelpful defaults for archived bugs.
The only other thing I could say, which may or may not be helpful for
your use case, is that Lisp programs shouldn't assume they will always
find point outside of invisible portion of the text, and instead
actively look for the first visible position after point.
This bug report was last modified 4 years and 148 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.