* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
@ 2016-03-21 20:19 Michael Heerdegen
2016-03-21 20:26 ` Michael Heerdegen
2016-03-21 21:11 ` Stefan Monnier
0 siblings, 2 replies; 21+ messages in thread
From: Michael Heerdegen @ 2016-03-21 20:19 UTC (permalink / raw)
To: 23079
Hello,
I try to give a recipe resembling a bug in Magit concerning hidden lines
and cursor movement. In some buffer (emacs -Q) do
(insert "111" "\n222\n"
(propertize "333\n444\n\n" 'invisible t)
"555\n666\n")
and move around with C-n, C-p. Then the cursor will appear over the
first "5" but point is actually located inside the invisible area. This
is the cause of our trouble.
(setq line-move-visual t) helps, but setting (setq goal-column 0) makes
it appear again.
For reference, this is the original report in Magit (including
screenshots):
https://github.com/magit/magit/issues/2592
Thanks,
Michael.
In GNU Emacs 25.0.92.11 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
of 2016-03-21 built on drachen
Repository revision: 76ef52267cf887e3e1aa6d25b3b16dd0601dd459
Windowing system distributor 'The X.Org Foundation', version 11.0.11802000
System Description: Debian GNU/Linux testing (stretch)
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-21 20:19 bug#23079: 25.0.92; Movement commands leave cursor in invisible line Michael Heerdegen
@ 2016-03-21 20:26 ` Michael Heerdegen
2016-03-21 21:11 ` Stefan Monnier
1 sibling, 0 replies; 21+ messages in thread
From: Michael Heerdegen @ 2016-03-21 20:26 UTC (permalink / raw)
To: 23079; +Cc: jonas
Hi,
I forgot to CC Jonas who cares about the bug in Magit.
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Hello,
>
> I try to give a recipe resembling a bug in Magit concerning hidden lines
> and cursor movement. In some buffer (emacs -Q) do
>
>
> (insert "111" "\n222\n"
> (propertize "333\n444\n\n" 'invisible t)
> "555\n666\n")
>
> and move around with C-n, C-p. Then the cursor will appear over the
> first "5" but point is actually located inside the invisible area. This
> is the cause of our trouble.
>
> (setq line-move-visual t) helps, but setting (setq goal-column 0) makes
> it appear again.
>
> For reference, this is the original report in Magit (including
> screenshots):
>
> https://github.com/magit/magit/issues/2592
>
>
> Thanks,
>
> Michael.
>
>
>
> In GNU Emacs 25.0.92.11 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
> of 2016-03-21 built on drachen
> Repository revision: 76ef52267cf887e3e1aa6d25b3b16dd0601dd459
> Windowing system distributor 'The X.Org Foundation', version 11.0.11802000
> System Description: Debian GNU/Linux testing (stretch)
>
> Configured features:
> XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
> LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-21 20:19 bug#23079: 25.0.92; Movement commands leave cursor in invisible line Michael Heerdegen
2016-03-21 20:26 ` Michael Heerdegen
@ 2016-03-21 21:11 ` Stefan Monnier
2016-03-21 22:29 ` Michael Heerdegen
` (2 more replies)
1 sibling, 3 replies; 21+ messages in thread
From: Stefan Monnier @ 2016-03-21 21:11 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 23079, jonas
tags 23079 notabug
thanks
> I try to give a recipe resembling a bug in Magit concerning hidden lines
> and cursor movement. In some buffer (emacs -Q) do
> (insert "111" "\n222\n"
> (propertize "333\n444\n\n" 'invisible t)
> "555\n666\n")
> and move around with C-n, C-p. Then the cursor will appear over the
> first "5" but point is actually located inside the invisible area.
That's normal: (get-pos-property <pos> 'invisible) returns nil in front
of "333" but t in front of "555", so point adjustment will try to move
point to right before "333" when we're in that invisible chunk.
IOW the position "right before 555" is actually considered as being
"inside the invisible area" whereas the position "right before 333" is
considered as being outside of it.
If you want point adjustment to move point to right before "555"
instead, you should change the stickiness of the `invisible' property so
as to change which boundary position is considered "inside" and which is
considered "outside".
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-21 21:11 ` Stefan Monnier
@ 2016-03-21 22:29 ` Michael Heerdegen
2016-03-22 1:27 ` Stefan Monnier
2016-03-21 22:54 ` Michael Heerdegen
2020-08-15 4:22 ` Stefan Kangas
2 siblings, 1 reply; 21+ messages in thread
From: Michael Heerdegen @ 2016-03-21 22:29 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 23079, jonas
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> That's normal: (get-pos-property <pos> 'invisible) returns nil in front
> of "333" but t in front of "555", so point adjustment will try to move
> point to right before "333" when we're in that invisible chunk.
Hmm, that perfectly makes sense.
> IOW the position "right before 555" is actually considered as being
> "inside the invisible area" whereas the position "right before 333" is
> considered as being outside of it.
>
> If you want point adjustment to move point to right before "555"
> instead, you should change the stickiness of the `invisible' property so
> as to change which boundary position is considered "inside" and which is
> considered "outside".
Seems that works only for the invisible text property. In Magit, they
use overlays to make text invisible, and stickiness of text properties
has not effect there.
This is what I tried:
(add-text-properties (point-min) (point-max)
'(front-sticky t rear-nonsticky t))
That helps for the recipe I gave here, but unfortunately not in Magit.
Michael.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-21 21:11 ` Stefan Monnier
2016-03-21 22:29 ` Michael Heerdegen
@ 2016-03-21 22:54 ` Michael Heerdegen
2020-08-15 4:22 ` Stefan Kangas
2 siblings, 0 replies; 21+ messages in thread
From: Michael Heerdegen @ 2016-03-21 22:54 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 23079, jonas
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> That's normal: (get-pos-property <pos> 'invisible) returns nil in front
> of "333" but t in front of "555", so point adjustment will try to move
> point to right before "333" when we're in that invisible chunk.
BTW, we also discussed whether we could hide the newline "before the
first invisible lines", and don't hide the newline following the last
line to make invisible instead. But we apparently can't do this because
(from "https://github.com/magit/magit/issues/2592"):
"e.g. the background color of headings of collapsed sections would not
be in affect all the way to the right edge of the window anymore"
and other drawbacks.
Michael.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-21 22:29 ` Michael Heerdegen
@ 2016-03-22 1:27 ` Stefan Monnier
2016-03-22 16:02 ` Michael Heerdegen
0 siblings, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2016-03-22 1:27 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 23079, jonas
> Seems that works only for the invisible text property. In Magit, they
> use overlays to make text invisible, and stickiness of text properties
> has not effect there.
For overlays, you need to use the insertion-type of the beg/end marker.
See the FRONT-ADVANCE and REAR-ADVANCE args of make-overlay.
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-22 1:27 ` Stefan Monnier
@ 2016-03-22 16:02 ` Michael Heerdegen
2016-03-22 16:16 ` Stefan Monnier
0 siblings, 1 reply; 21+ messages in thread
From: Michael Heerdegen @ 2016-03-22 16:02 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 23079, jonas
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > Seems that works only for the invisible text property. In Magit,
> > they use overlays to make text invisible, and stickiness of text
> > properties has not effect there.
>
> For overlays, you need to use the insertion-type of the beg/end marker.
> See the FRONT-ADVANCE and REAR-ADVANCE args of make-overlay.
Hmm, that doesn't seem to work:
(progn
(insert "111" "\n222\n")
(let ((beg (point)) end)
(insert "333\n444\n")
(setq end (point))
(insert "555\n666\n")
(overlay-put
(make-overlay beg end nil t t)
'invisible t)
(goto-char 1)
(hl-line-mode +1)))
Michael.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-22 16:02 ` Michael Heerdegen
@ 2016-03-22 16:16 ` Stefan Monnier
2016-03-22 16:48 ` Michael Heerdegen
0 siblings, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2016-03-22 16:16 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 23079, jonas
>> > Seems that works only for the invisible text property. In Magit,
>> > they use overlays to make text invisible, and stickiness of text
>> > properties has not effect there.
>> For overlays, you need to use the insertion-type of the beg/end marker.
>> See the FRONT-ADVANCE and REAR-ADVANCE args of make-overlay.
> Hmm, that doesn't seem to work:
> (progn
> (insert "111" "\n222\n")
> (let ((beg (point)) end)
> (insert "333\n444\n")
> (setq end (point))
> (insert "555\n666\n")
> (overlay-put
> (make-overlay beg end nil t t)
> 'invisible t)
> (goto-char 1)
> (hl-line-mode +1)))
The default "stickiness" of overlay boundaries is the inverse of that if
text-properties, for some reason. So, this test above suffers from the
bug#19200, but other than that, it seems to work correctly for me
(i.e. it prefers putting point in front of "333" rather than in front
of "555").
And if I remove the "nil t t" args to make-overlay, then
point-adjustment correctly tries to put point in front of "555" instead
of putting it in front of "333".
At least, in my tests,
Stefan
PS: Notice that the hl-line-highlighting is sometimes off, because it's
performed in post-command-hook, which is run *before* point-adjustment.
hl-line-mode should probably be changed to use pre-redisplay-function to
try and avoid this problem.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-22 16:16 ` Stefan Monnier
@ 2016-03-22 16:48 ` Michael Heerdegen
2016-03-23 1:59 ` Stefan Monnier
0 siblings, 1 reply; 21+ messages in thread
From: Michael Heerdegen @ 2016-03-22 16:48 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 23079, jonas
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> The default "stickiness" of overlay boundaries is the inverse of that if
> text-properties, for some reason. So, this test above suffers from the
> bug#19200, but other than that, it seems to work correctly for me
> (i.e. it prefers putting point in front of "333" rather than in front
> of "555").
>
> And if I remove the "nil t t" args to make-overlay, then
> point-adjustment correctly tries to put point in front of "555" instead
> of putting it in front of "333".
Ok, we are coming closer...
They use the default stickiness for their overlays. Nonetheless, the
behavior is the same as with "nil t t".
_But_ their local binding of post-command-hook looks like (t
magit-section-update-highlight).
When I set it to (t) only, the issue is fixed (but the highlighting
update doesn't work anymore, of course)!
magit-section-update-highlight is
#+begin_src emacs-lisp
(defun magit-section-update-highlight ()
(let ((section (magit-current-section)))
(unless (eq section magit-section-highlighted-section)
(let ((inhibit-read-only t)
(deactivate-mark nil)
(selection (magit-region-sections)))
(mapc #'delete-overlay magit-section-highlight-overlays)
(setq magit-section-unhighlight-sections
magit-section-highlighted-sections
magit-section-highlighted-sections nil)
(unless (eq section magit-root-section)
(run-hook-with-args-until-success
'magit-section-highlight-hook section selection))
(--each magit-section-unhighlight-sections
(run-hook-with-args-until-success
'magit-section-unhighlight-hook it selection))
(restore-buffer-modified-p nil)
(unless (eq magit-section-highlighted-section section)
(setq magit-section-highlighted-section
(unless (magit-section-hidden section) section))))
(setq deactivate-mark nil))))
#+end_src
This function doesn't move point, but it somehow interferes with point
adjustment in another way.
Michael
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-22 16:48 ` Michael Heerdegen
@ 2016-03-23 1:59 ` Stefan Monnier
2016-03-23 3:41 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2016-03-23 1:59 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 23079, jonas
> (let ((inhibit-read-only t)
> (deactivate-mark nil)
> (selection (magit-region-sections)))
> (mapc #'delete-overlay magit-section-highlight-overlays)
> (setq magit-section-unhighlight-sections
> magit-section-highlighted-sections
> magit-section-highlighted-sections nil)
> (unless (eq section magit-root-section)
> (run-hook-with-args-until-success
> 'magit-section-highlight-hook section selection))
> (--each magit-section-unhighlight-sections
> (run-hook-with-args-until-success
> 'magit-section-unhighlight-hook it selection))
> (restore-buffer-modified-p nil)
Hmm... what kind of buffer modifications might happen in here?
I think this might be the problem: point-adjustment is only applied after
"movement commands" and is disabled if the buffer was modified during
the course of the command (including post-command-hook).
[ This is mostly due to the simplistic way we keep track of the
"previous state", which we can't trust if the buffer was modified. ]
> This function doesn't move point, but it somehow interferes with point
> adjustment in another way.
It's difficult to adjust point without risking adverse effects in corner
cases (typically problems like "repeated C-n gets stuck" or "forward-foo
moves backward"), so point-adjustment is conservative to try and make
sure it's only done when we're sure it's "safe".
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-23 1:59 ` Stefan Monnier
@ 2016-03-23 3:41 ` Eli Zaretskii
2016-03-23 11:23 ` Stefan Monnier
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2016-03-23 3:41 UTC (permalink / raw)
To: Stefan Monnier; +Cc: michael_heerdegen, 23079, jonas
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 22 Mar 2016 21:59:38 -0400
> Cc: 23079@debbugs.gnu.org, jonas@bernoul.li
>
> > (let ((inhibit-read-only t)
> > (deactivate-mark nil)
> > (selection (magit-region-sections)))
> > (mapc #'delete-overlay magit-section-highlight-overlays)
> > (setq magit-section-unhighlight-sections
> > magit-section-highlighted-sections
> > magit-section-highlighted-sections nil)
> > (unless (eq section magit-root-section)
> > (run-hook-with-args-until-success
> > 'magit-section-highlight-hook section selection))
> > (--each magit-section-unhighlight-sections
> > (run-hook-with-args-until-success
> > 'magit-section-unhighlight-hook it selection))
> > (restore-buffer-modified-p nil)
>
> Hmm... what kind of buffer modifications might happen in here?
Deletion of overlays, perhaps? And there are all those hooks which
might not be nil.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-23 3:41 ` Eli Zaretskii
@ 2016-03-23 11:23 ` Stefan Monnier
2016-03-23 15:12 ` Michael Heerdegen
0 siblings, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2016-03-23 11:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael_heerdegen, 23079, jonas
>> Hmm... what kind of buffer modifications might happen in here?
> Deletion of overlays, perhaps?
AFAIK this is not a buffer modification (it doesn't affect MODIFF nor
buffer-modified-p).
> And there are all those hooks which might not be nil.
Yes, that's what my question wants to know ;-)
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-23 11:23 ` Stefan Monnier
@ 2016-03-23 15:12 ` Michael Heerdegen
2016-03-24 2:07 ` Michael Heerdegen
0 siblings, 1 reply; 21+ messages in thread
From: Michael Heerdegen @ 2016-03-23 15:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 23079, jonas
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > And there are all those hooks which might not be nil.
>
> Yes, that's what my question wants to know ;-)
I'll have a look.
Thanks,
Michael.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-23 15:12 ` Michael Heerdegen
@ 2016-03-24 2:07 ` Michael Heerdegen
2016-03-24 21:32 ` Michael Heerdegen
0 siblings, 1 reply; 21+ messages in thread
From: Michael Heerdegen @ 2016-03-24 2:07 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 23079, jonas
Michael Heerdegen <michael_heerdegen@web.de> writes:
> I'll have a look.
Yes, indeed, at least one of those hooks seems to change text properties.
Can't look into it further, it's already too late.
Michael.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-24 2:07 ` Michael Heerdegen
@ 2016-03-24 21:32 ` Michael Heerdegen
2016-03-24 22:01 ` Stefan Monnier
0 siblings, 1 reply; 21+ messages in thread
From: Michael Heerdegen @ 2016-03-24 21:32 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 23079, jonas
Michael Heerdegen <michael_heerdegen@web.de> writes:
> Yes, indeed, at least one of those hooks seems to change text
> properties. Can't look into it further, it's already too late.
Yes, I verified that it does.
So...what can we do? Can we salvage (sorry if this is the wrong word)
the cursor adjustment somehow?
Thanks,
Michael.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-24 21:32 ` Michael Heerdegen
@ 2016-03-24 22:01 ` Stefan Monnier
2016-03-25 11:42 ` Jonas Bernoulli
0 siblings, 1 reply; 21+ messages in thread
From: Stefan Monnier @ 2016-03-24 22:01 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: 23079, jonas
>> Yes, indeed, at least one of those hooks seems to change text
>> properties. Can't look into it further, it's already too late.
> Yes, I verified that it does.
> So...what can we do? Can we salvage (sorry if this is the wrong word)
> the cursor adjustment somehow?
Hmm... not without changes either to Emacs's C code (so as to perform
point-adjustment even if some changes were made to the buffer), or to
Magit's code (so as not to touch text-properties during
magit-section-update-highlight, e.g. using overlays instead).
Stefan
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-24 22:01 ` Stefan Monnier
@ 2016-03-25 11:42 ` Jonas Bernoulli
2016-03-25 13:53 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Jonas Bernoulli @ 2016-03-25 11:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Michael Heerdegen, 23079
>>> Yes, indeed, at least one of those hooks seems to change text
>>> properties. Can't look into it further, it's already too late.
>> Yes, I verified that it does.
>> So...what can we do? Can we salvage (sorry if this is the wrong word)
>> the cursor adjustment somehow?
>
> Hmm... not without changes either to Emacs's C code (so as to perform
> point-adjustment even if some changes were made to the buffer), or to
> Magit's code (so as not to touch text-properties during
> magit-section-update-highlight, e.g. using overlays instead).
If I remember correctly we started to use text-properties here because
Eli occationally tells us that we should not abuse overlays ;-)
It should easily be possible to go back to text-properties.
(I haven't followed this conversation closely because I am on a break.)
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-25 11:42 ` Jonas Bernoulli
@ 2016-03-25 13:53 ` Eli Zaretskii
2016-03-26 10:21 ` Jonas Bernoulli
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2016-03-25 13:53 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: michael_heerdegen, 23079, monnier
> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, Eli Zaretskii <eliz@gnu.org>, 23079@debbugs.gnu.org
> Date: Fri, 25 Mar 2016 12:42:10 +0100
>
> If I remember correctly we started to use text-properties here because
> Eli occationally tells us that we should not abuse overlays ;-)
Eli also told you not to abuse invisible text in general. (I still
don't understand why Magit wants to hide text it itself produced,
instead of just deleting the part(s) it doesn't want to show.)
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-25 13:53 ` Eli Zaretskii
@ 2016-03-26 10:21 ` Jonas Bernoulli
0 siblings, 0 replies; 21+ messages in thread
From: Jonas Bernoulli @ 2016-03-26 10:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: michael_heerdegen, 23079, monnier
> I still don't understand why Magit wants to hide text it itself
> produced, instead of just deleting the part(s) it doesn't want to
> show.
It saves us from having to perform potentially expensive calculations
repeatedly when a section is being expanded and collapsed multiple
times. Obviously a cache would help, and that's what I have in mind
for Magit v3.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2016-03-21 21:11 ` Stefan Monnier
2016-03-21 22:29 ` Michael Heerdegen
2016-03-21 22:54 ` Michael Heerdegen
@ 2020-08-15 4:22 ` Stefan Kangas
2020-10-01 12:26 ` Stefan Kangas
2 siblings, 1 reply; 21+ messages in thread
From: Stefan Kangas @ 2020-08-15 4:22 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Michael Heerdegen, 23079, jonas
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> tags 23079 notabug
> thanks
>
>> I try to give a recipe resembling a bug in Magit concerning hidden lines
>> and cursor movement. In some buffer (emacs -Q) do
>
>> (insert "111" "\n222\n"
>> (propertize "333\n444\n\n" 'invisible t)
>> "555\n666\n")
>
>> and move around with C-n, C-p. Then the cursor will appear over the
>> first "5" but point is actually located inside the invisible area.
>
> That's normal: (get-pos-property <pos> 'invisible) returns nil in front
> of "333" but t in front of "555", so point adjustment will try to move
> point to right before "333" when we're in that invisible chunk.
>
> IOW the position "right before 555" is actually considered as being
> "inside the invisible area" whereas the position "right before 333" is
> considered as being outside of it.
>
> If you want point adjustment to move point to right before "555"
> instead, you should change the stickiness of the `invisible' property so
> as to change which boundary position is considered "inside" and which is
> considered "outside".
This was tagged notabug, then started discussing possible changes in
Magit, and then nothing more happened in 4 years. So is there anything
more to do here or can this be closed?
Best regards,
Stefan Kangas
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#23079: 25.0.92; Movement commands leave cursor in invisible line
2020-08-15 4:22 ` Stefan Kangas
@ 2020-10-01 12:26 ` Stefan Kangas
0 siblings, 0 replies; 21+ messages in thread
From: Stefan Kangas @ 2020-10-01 12:26 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Michael Heerdegen, 23079-done, jonas
Stefan Kangas <stefan@marxist.se> writes:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>> tags 23079 notabug
>> thanks
>>
>>> I try to give a recipe resembling a bug in Magit concerning hidden lines
>>> and cursor movement. In some buffer (emacs -Q) do
>>
>>> (insert "111" "\n222\n"
>>> (propertize "333\n444\n\n" 'invisible t)
>>> "555\n666\n")
>>
>>> and move around with C-n, C-p. Then the cursor will appear over the
>>> first "5" but point is actually located inside the invisible area.
>>
>> That's normal: (get-pos-property <pos> 'invisible) returns nil in front
>> of "333" but t in front of "555", so point adjustment will try to move
>> point to right before "333" when we're in that invisible chunk.
>>
>> IOW the position "right before 555" is actually considered as being
>> "inside the invisible area" whereas the position "right before 333" is
>> considered as being outside of it.
>>
>> If you want point adjustment to move point to right before "555"
>> instead, you should change the stickiness of the `invisible' property so
>> as to change which boundary position is considered "inside" and which is
>> considered "outside".
>
> This was tagged notabug, then started discussing possible changes in
> Magit, and then nothing more happened in 4 years. So is there anything
> more to do here or can this be closed?
More information was requested, but none was given within 6 weeks, so
I'm closing this bug. If there is anything more to do here, please
reply to this email (use "Reply to all" in your email client) and we can
reopen the bug report.
Best regards,
Stefan Kangas
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2020-10-01 12:26 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-21 20:19 bug#23079: 25.0.92; Movement commands leave cursor in invisible line Michael Heerdegen
2016-03-21 20:26 ` Michael Heerdegen
2016-03-21 21:11 ` Stefan Monnier
2016-03-21 22:29 ` Michael Heerdegen
2016-03-22 1:27 ` Stefan Monnier
2016-03-22 16:02 ` Michael Heerdegen
2016-03-22 16:16 ` Stefan Monnier
2016-03-22 16:48 ` Michael Heerdegen
2016-03-23 1:59 ` Stefan Monnier
2016-03-23 3:41 ` Eli Zaretskii
2016-03-23 11:23 ` Stefan Monnier
2016-03-23 15:12 ` Michael Heerdegen
2016-03-24 2:07 ` Michael Heerdegen
2016-03-24 21:32 ` Michael Heerdegen
2016-03-24 22:01 ` Stefan Monnier
2016-03-25 11:42 ` Jonas Bernoulli
2016-03-25 13:53 ` Eli Zaretskii
2016-03-26 10:21 ` Jonas Bernoulli
2016-03-21 22:54 ` Michael Heerdegen
2020-08-15 4:22 ` Stefan Kangas
2020-10-01 12:26 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).