bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Alex]

This bug report originated from
https://github.com/magit/magit/issues/2735

If scroll-conservatively is higher than SCROLL_LIMIT (100), then trying
to move down past an overlay with the `before-string' property may put
the point at the top of the window rather than at the next available
point. This only occurs when the overlay's line is only partially
visible.

This can be reproduced without magit, but it's easiest to reproduce with
magit:

1. Start in emacs -Q. and load magit.
2. Go to version.el in emacs' repo
3. Set scroll-conservatively to a value higher than 100.
4. magit-blame.
5. M-g c 1350
6. Press C-f

The point is now at 1351, but now it's at the top of the screen.

The above should work if the screen is maximized on a 1080p screen.
Otherwise you can just keep hitting `n' until you reach a
partially-visible overlay.

In GNU Emacs 25.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.20.6)
 of 2016-07-25 built on buildhw-08.phx2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.11804000
Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XWIDGETS

Major mode: Emacs-Lisp

Minor modes in effect:
  magit-auto-revert-mode: t
  auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Features:
(shadow sort mail-extr emacsbug sendmail linum magit-blame magit-stash
magit-bisect magit-remote magit-commit magit-sequence magit magit-apply
magit-wip magit-log magit-diff smerge-mode magit-core magit-autorevert
autorevert filenotify magit-process magit-popup magit-mode magit-git crm
magit-section magit-utils git-commit log-edit message dired rfc822 mml
mml-sec epg mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums mailabbrev mail-utils gmm-utils mailheader pcvs-util
with-editor async-bytecomp async tramp-sh tramp tramp-compat auth-source
cl-seq eieio eieio-core cl-macs gnus-util mm-util help-fns mail-prsvr
password-cache tramp-loaddefs trampver ucs-normalize shell pcomplete
comint ansi-color ring format-spec advice server dash vc-git diff-mode
easy-mmode bug-reference add-log finder-inf tex-site slime-autoloads
info package epg-config seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting xwidget-internal move-toolbar
gtk x-toolkit x multi-tty make-network-process emacs)

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Date: Sun, 07 Aug 2016 15:15:51 -0600
> 
> 
> This bug report originated from
> https://github.com/magit/magit/issues/2735
> 
> If scroll-conservatively is higher than SCROLL_LIMIT (100), then trying
> to move down past an overlay with the `before-string' property may put
> the point at the top of the window rather than at the next available
> point. This only occurs when the overlay's line is only partially
> visible.
> 
> This can be reproduced without magit, but it's easiest to reproduce with
> magit:

I'd really appreciate if you could post a recipe that doesn't need
magit.

Thanks.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Alex]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd really appreciate if you could post a recipe that doesn't need
> magit.
>
> Thanks.

Is there a way to save a buffer including all overlays so that both the
text and overlays can be regenerated later? I can't seem to find an
Emacs function for the job. It would have made getting the recipe a lot
simpler.

I've attached a recipe file below. Once the recipe function is executed,
open the `test' buffer and do C-n as desired (or try M-g c 1350 and C-f
as above).


[-- Attachment #2: recipe --]
[-- Type: application/emacs-lisp, Size: 38377 bytes --]

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 24179@debbugs.gnu.org
> Date: Sun, 07 Aug 2016 23:42:33 -0600
> 
> Is there a way to save a buffer including all overlays so that both the
> text and overlays can be regenerated later?

I'm not sure.

> I've attached a recipe file below. Once the recipe function is executed,
> open the `test' buffer and do C-n as desired (or try M-g c 1350 and C-f
> as above).

Thanks, this is very helpful.  I think I fixed the problem on the
master branch, please test.

Btw, magit-blame could be nicer to the display engine by placing a
'cursor' property on the first character of each before-string it
creates to show the blamed commit.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, this is very helpful.  I think I fixed the problem on the
> master branch, please test.

It appears that the point lands on the correct position, thanks.

Unfortunately it seems like there's a brief delay (that is only
noticeable in magit-blame) now where the point is temporarily in the
wrong place (as before), before quickly moving to the correct position.
That's much better than before, though.

> Btw, magit-blame could be nicer to the display engine by placing a
> 'cursor' property on the first character of each before-string it
> creates to show the blamed commit.

Perhaps that would help with the above delay?

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 24179@debbugs.gnu.org
> Date: Mon, 08 Aug 2016 10:35:37 -0600
> 
> Unfortunately it seems like there's a brief delay (that is only
> noticeable in magit-blame) now where the point is temporarily in the
> wrong place (as before), before quickly moving to the correct position.

Not on my system, not after C-f at position 1350 anyway.

However, what you describe happens elsewhere in magit-blame's display.
E.g., I see it when I do "M-g c 1350 RET" as part of the recipe.  So
this is a separate issue.

In general, overlay strings with newlines are hard on the display
engine, especially when line-move-visual is on and under
scroll-conservatively.

> > Btw, magit-blame could be nicer to the display engine by placing a
> > 'cursor' property on the first character of each before-string it
> > creates to show the blamed commit.
> 
> Perhaps that would help with the above delay?

Could be.  It will also eliminate those annoying jumps of the cursor
when it needs to "step over" the lines that come from before-strings.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

> Not on my system, not after C-f at position 1350 anyway.
>
> However, what you describe happens elsewhere in magit-blame's display.
> E.g., I see it when I do "M-g c 1350 RET" as part of the recipe.  So
> this is a separate issue.

You're right, though it also seems to happen when using C-n. I tried
turning off line-move-visual and the delay is still there. Hopefully the
cursor property will help.

Thanks.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 24179@debbugs.gnu.org
> Date: Mon, 08 Aug 2016 11:22:29 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Not on my system, not after C-f at position 1350 anyway.
> >
> > However, what you describe happens elsewhere in magit-blame's display.
> > E.g., I see it when I do "M-g c 1350 RET" as part of the recipe.  So
> > this is a separate issue.
> 
> You're right, though it also seems to happen when using C-n. I tried
> turning off line-move-visual and the delay is still there. Hopefully the
> cursor property will help.

OK.  If no new issues come up due to my changes, please close the bug
in a few days.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 24179@debbugs.gnu.org
> Date: Mon, 08 Aug 2016 11:22:29 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Not on my system, not after C-f at position 1350 anyway.
> >
> > However, what you describe happens elsewhere in magit-blame's display.
> > E.g., I see it when I do "M-g c 1350 RET" as part of the recipe.  So
> > this is a separate issue.
> 
> You're right, though it also seems to happen when using C-n. I tried
> turning off line-move-visual and the delay is still there.

I have now fixed that problem as well.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Alex]

tags 24179 fixed
close 24179 
quit

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: 24179@debbugs.gnu.org
>> Date: Mon, 08 Aug 2016 11:22:29 -0600

>> You're right, though it also seems to happen when using C-n. I tried
>> turning off line-move-visual and the delay is still there.
>
> I have now fixed that problem as well.

Thanks, I don't see it anymore with C-n. It's expected that the delay
with M-g c and magit-blame's `n' command is still present, right?

Though your new commit does seem to lessen those delays, if that means
anything.

> OK.  If no new issues come up due to my changes, please close the bug
> in a few days.

Hopefully the above did that.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Eli Zaretskii]

tags 24179 fixed
close 24179 
quit

> From: Alex <agrambot@gmail.com>
> Cc: 24179@debbugs.gnu.org
> Date: Thu, 11 Aug 2016 16:20:07 -0600
> 
> >> You're right, though it also seems to happen when using C-n. I tried
> >> turning off line-move-visual and the delay is still there.
> >
> > I have now fixed that problem as well.
> 
> Thanks, I don't see it anymore with C-n. It's expected that the delay
> with M-g c and magit-blame's `n' command is still present, right?

I don't see any perceptible delay here, but maybe I missed something.
Do some "M-g c" work faster than others?  Or some other motion
commands are faster than "M-g c 1350 RET"?  If so, can you give a
recipe for a "fast" and a "slow" command?

In general, setting scroll-conservatively to a large value makes
redisplay slightly slower, because in some situations it must work
harder to find the smallest possible scroll amount.  If a
before-string inserted by magit-blame uses up many screen lines, the
fix I added might indeed cause a slowdown, although they'll have to be
quite a lot of screen lines for that to become perceptible, I think.

Another potential reason for slower redisplay, specific to magit-blame
and similar modes, is that a significant proportion of lines in a
typical window comes from overlay strings, not from buffer text.  When
Emacs needs to determine the position of window-start for next
redisplay, it starts from point and goes back till it finds a suitable
buffer position, which would put point some specific number of pixels
from the window-start.  When Emacs goes back, it uses the number of
lines in the buffer as the first approximation, then adjusts that
place as needed.  With many display or overlay strings in a window,
that first approximation is usually way off, so the process of
adjusting it to find the correct place needs to consider more
potential candidates, and this takes longer.

> Though your new commit does seem to lessen those delays, if that means
> anything.

The original delay was not a delay.  What happened is that the first
redisplay after "M-g c 1350 RET" would end up with point off the
screen, and the cursor at the end of the first screen line.
Immediately after that another redisplay would fix that by scrolling
the window.  So it took 2 redisplay cycles to react to the command;
now it takes only one.

> > OK.  If no new issues come up due to my changes, please close the bug
> > in a few days.
> 
> Hopefully the above did that.

No, it didn't.  When you include control commands in a message, you
should BCC control@debbugs.gnu.org for the bug tracker to take notice
(like I did with tis message).  If you want to just close the bug (as
opposed to add some tags), an easier way is to CC
24179-done@debbugs.gnu.org.

Thanks.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see any perceptible delay here, but maybe I missed something.
> Do some "M-g c" work faster than others?  Or some other motion
> commands are faster than "M-g c 1350 RET"?  If so, can you give a
> recipe for a "fast" and a "slow" command?

Using the recipe function above, try M-g c 1737. That temporarily leaves
the point at the top before going to the correct position. M-g c 1700
does not do this.

Using magit-blame in version.el with emacs maximized do M-g c 1148 and
press `n' one or two times. One of these should briefly show the cursor
at the top of the screen.

> Another potential reason for slower redisplay, specific to magit-blame
> and similar modes, is that a significant proportion of lines in a
> typical window comes from overlay strings, not from buffer text.  When
> Emacs needs to determine the position of window-start for next
> redisplay, it starts from point and goes back till it finds a suitable
> buffer position, which would put point some specific number of pixels
> from the window-start.  When Emacs goes back, it uses the number of
> lines in the buffer as the first approximation, then adjusts that
> place as needed.  With many display or overlay strings in a window,
> that first approximation is usually way off, so the process of
> adjusting it to find the correct place needs to consider more
> potential candidates, and this takes longer.

Alright, that makes sense.

> The original delay was not a delay.  What happened is that the first
> redisplay after "M-g c 1350 RET" would end up with point off the
> screen, and the cursor at the end of the first screen line.
> Immediately after that another redisplay would fix that by scrolling
> the window.  So it took 2 redisplay cycles to react to the command;
> now it takes only one.

OK, that would explain it. By "delay" I was referring to this momentary
period where the cursor is shown at the end of the top screen line.

Is it necessary to be in this wrong position for a redisplay cycle?

> No, it didn't.  When you include control commands in a message, you
> should BCC control@debbugs.gnu.org for the bug tracker to take notice

Ah, right. Thanks.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 24179@debbugs.gnu.org
> Date: Fri, 12 Aug 2016 16:01:19 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't see any perceptible delay here, but maybe I missed something.
> > Do some "M-g c" work faster than others?  Or some other motion
> > commands are faster than "M-g c 1350 RET"?  If so, can you give a
> > recipe for a "fast" and a "slow" command?
> 
> Using the recipe function above, try M-g c 1737. That temporarily leaves
> the point at the top before going to the correct position. M-g c 1700
> does not do this.

Yes, I see that, thanks.  I will think if something can be done in
that case.

> Is it necessary to be in this wrong position for a redisplay cycle?

I'm not sure I understand the question.  Redisplay cycles happen in
Emacs all the time when Emacs is idle, but usually they quickly
determine that nothing has to be done, so you don't see them
happening.  In this case, Emacs sees that point is not inside the
window, so it attempts to correct that.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, I see that, thanks.  I will think if something can be done in
> that case.

Thanks for looking into this.

> I'm not sure I understand the question.  Redisplay cycles happen in
> Emacs all the time when Emacs is idle, but usually they quickly
> determine that nothing has to be done, so you don't see them
> happening.  In this case, Emacs sees that point is not inside the
> window, so it attempts to correct that.

I meant that if it was necessary to show the point in the wrong position
in this case even for a very brief period of time. That is, could Emacs
correct the position before displaying the point to the user?

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 24179@debbugs.gnu.org
> Date: Sat, 13 Aug 2016 10:59:15 -0600
> 
> I meant that if it was necessary to show the point in the wrong position
> in this case even for a very brief period of time. That is, could Emacs
> correct the position before displaying the point to the user?

Teaching Emacs not to get into such situations is what takes to fix
these problems.  Until then, no, Emacs cannot correct the position
before showing the window, because if it did, the problem wouldn't
have existed in the first place.

When Emacs is about to redisplay a window, its main task is to figure
out what should be the window-start position.  If it decides
incorrectly (which is what happens in this case), the window will
display incorrectly.  The display engine tries to detect these
situations and recover from them, but it sometimes fails.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Eli Zaretskii]

> Date: Sat, 13 Aug 2016 09:52:10 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24179@debbugs.gnu.org
> 
> > From: Alex <agrambot@gmail.com>
> > Cc: 24179@debbugs.gnu.org
> > Date: Fri, 12 Aug 2016 16:01:19 -0600
> > 
> > Using the recipe function above, try M-g c 1737. That temporarily leaves
> > the point at the top before going to the correct position. M-g c 1700
> > does not do this.
> 
> Yes, I see that, thanks.  I will think if something can be done in
> that case.

Should be fixed now.

bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 13 Aug 2016 09:52:10 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 24179@debbugs.gnu.org
>> 
>> > From: Alex <agrambot@gmail.com>
>> > Cc: 24179@debbugs.gnu.org
>> > Date: Fri, 12 Aug 2016 16:01:19 -0600
>> > 
>> > Using the recipe function above, try M-g c 1737. That temporarily leaves
>> > the point at the top before going to the correct position. M-g c 1700
>> > does not do this.
>> 
>> Yes, I see that, thanks.  I will think if something can be done in
>> that case.
>
> Should be fixed now.

Nice, thanks a lot. It solved that case and the other ones discussed as
well.

bug#24179: 24179

[Jonas Bernoulli]

Thanks Eli!

> Btw, magit-blame could be nicer to the display engine by placing a
> 'cursor' property on the first character of each before-string it
> creates to show the blamed commit.

After reading the documentation, I cannot quite figure what I am
supposed to do.  Given this:

(with-current-buffer (get-buffer-create "demo")
  (pop-to-buffer (current-buffer))
  (erase-buffer)
  (insert "one\ntwo\nthree")
  (backward-word 2)
  (let ((ov (make-overlay (point)
                          (save-excursion
                            (forward-line 1)
                            (point))))
        (heading "before two\n"))
    (overlay-put ov 'before-string heading)
    (overlay-put ov 'the-value "two")
    (overlay-put ov 'evaporate t)))

I think I am supposed to change it to:

(with-current-buffer (get-buffer-create "demo")
  (pop-to-buffer (current-buffer))
  (erase-buffer)
  (insert "one\ntwo\nthree")
  (backward-word 2)
  (let ((ov (make-overlay (point)
                          (save-excursion
                            (forward-line 1)
                            (point))))
        (heading "before two\n"))
    (put-text-property 0 1 'cursor (length heading) heading)
    (overlay-put ov 'before-string heading)
    (overlay-put ov 'the-value "two")
    (overlay-put ov 'evaporate t)))

However I would then expect that it would become possible for the cursor
to be displayed "on" the "b" because of this: "In other words, the
string character with the ‘cursor’ property of any non-‘nil’ value is
the character where to display the cursor.  The value of the property
says for which buffer positions to display the cursor there."

one
*efore two
two
three

That would be a change in behavior* but I am not seeing any change so I
am unsure whether I am doing this all wrong.  If so, then please correct
the above code.

* However if that is possible, I would prefer to use the `cursor'
property to provide the hint to the display engine that the cursor
should keep ending up here (as it does without fiddling with `cursor' at
all):

one
before two
*wo
three

Given "the cursor will be displayed on this character for any buffer
position in the range `[OVPOS..OVPOS+N)'", I don't see how I can say
"display the cursor HERE instead of at the positions BEFORE HERE as
specified by N".

bug#24179: 24179

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Date: Thu, 11 Aug 2016 18:39:54 +0200
> 
> (with-current-buffer (get-buffer-create "demo")
>   (pop-to-buffer (current-buffer))
>   (erase-buffer)
>   (insert "one\ntwo\nthree")
>   (backward-word 2)
>   (let ((ov (make-overlay (point)
>                           (save-excursion
>                             (forward-line 1)
>                             (point))))
>         (heading "before two\n"))
>     (put-text-property 0 1 'cursor (length heading) heading)
>     (overlay-put ov 'before-string heading)
>     (overlay-put ov 'the-value "two")
>     (overlay-put ov 'evaporate t)))
> 
> However I would then expect that it would become possible for the cursor
> to be displayed "on" the "b" because of this: "In other words, the
> string character with the ‘cursor’ property of any non-‘nil’ value is
> the character where to display the cursor.  The value of the property
> says for which buffer positions to display the cursor there."
> 
> one
> *efore two
> two
> three
> 
> That would be a change in behavior* but I am not seeing any change so I
> am unsure whether I am doing this all wrong.  If so, then please correct
> the above code.

It looks like I misremembered: before-strings cannot benefit from this
feature, because they don't conceal any buffer positions.  Emacs only
considers the cursor property when the buffer position of point is not
visible on the screen, so you need to use 'display' properties.  Sorry
about that.

Here's an example that will allow you to experiment:

 (setq s1 "<dot>")
 (setq s2 (concat "<c" (propertize "o" 'cursor t) "mma>"))
 (setq c1 (propertize "..." 'display s1))
 (setq c2 (propertize ",,," 'display s2))
 (insert "abc" c1 "def" c2 "xyz" c1 c2 "123" c2 "456" c1 c2 c1 "789" c2 "end\n")


> * However if that is possible, I would prefer to use the `cursor'
> property to provide the hint to the display engine that the cursor
> should keep ending up here (as it does without fiddling with `cursor' at
> all):
> 
> one
> before two
> *wo
> three

That already happens, doesn't it?

bug#24179: 24179

[Jonas Bernoulli]

> It looks like I misremembered: before-strings cannot benefit from this
> feature, because they don't conceal any buffer positions.

The manual mentions "before-strings" in the description of "cursor".
That should probably be changed in that case.

> Here's an example that will allow you to experiment:

Thanks.

>> one
>> before two
>> *wo
>> three
>
> That already happens, doesn't it?

Yes.  All good ;-)

bug#24179: 24179

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: 24179@debbugs.gnu.org
> Date: Thu, 11 Aug 2016 20:29:58 +0200
> 
> > It looks like I misremembered: before-strings cannot benefit from this
> > feature, because they don't conceal any buffer positions.
> 
> The manual mentions "before-strings" in the description of "cursor".
> That should probably be changed in that case.

There's a subtlety here: the before-strings and after-strings can
either conceal some buffer text (i.e. be displayed instead of that
text) or not.  The cursor property will only be in effect in the
former case, whereas magit-bame uses the latter.

So the manual is not wrong, it just doesn't reveal this subtlety.

bug#24179: 24179

[Eli Zaretskii]

> Date: Thu, 11 Aug 2016 22:55:58 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 24179@debbugs.gnu.org
> 
> So the manual is not wrong, it just doesn't reveal this subtlety.

It does now.

bug#24179: 24179

[Jonas Bernoulli]

Thanks again Eli.