bug#29198: Cursor fringe arrow indicator not updating.

bug#29198: Cursor fringe arrow indicator not updating.

[Keith David Bershatsky]

The following code works fine with no user configuration in Emacs 25.3.  However, it does not work well with the current version of the master branch.  The overlay arrow indicator is not updating as the user moves up or down in the buffer with the keyboard arrow keys.

Step 1:  Open an Emacs built from the current master branch.

Step 2:  Got to the scratch buffer and evaluate the code below.

Step 3:  Maneuver up and down with the arrow keys navigating the code below.  The fringe bitmap indicator should track the vertical cursor position, but it does not work.


(defface +-left-fringe-cursor-face
  '((t (:foreground "firebrick")))
  "Face for `+-left-fringe-cursor-face'."
  :group '+-mode)

(defun set-fringe-cursor ()
"Doc-string"
  (if (not (and (eobp) (bolp)))
     (setq +-left-fringe-overlay-position (copy-marker (line-beginning-position)))
    (setq +-left-fringe-overlay-position  nil)))

(define-fringe-bitmap '+-cursor-left-fringe-bitmap [128 192 96 48 24 48 96 192 128] 9 8 'center)
(set-fringe-bitmap-face '+-cursor-left-fringe-bitmap '+-left-fringe-cursor-face)

;;; `overlay-arrow-bitmap' is a special SYMBOL defined in xdisp.c.
(defvar +-left-fringe-overlay-position nil
  "Doc-string.")
(make-variable-buffer-local '+-left-fringe-overlay-position)
(add-to-list 'overlay-arrow-variable-list '+-left-fringe-overlay-position)
(put '+-left-fringe-overlay-position 'overlay-arrow-bitmap '+-cursor-left-fringe-bitmap)

(add-hook 'post-command-hook 'set-fringe-cursor 'append 'local)

bug#29198: Cursor fringe arrow indicator not updating.

[Eli Zaretskii]

> Date: Tue, 07 Nov 2017 11:57:49 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> The following code works fine with no user configuration in Emacs 25.3.  However, it does not work well with the current version of the master branch.  The overlay arrow indicator is not updating as the user moves up or down in the buffer with the keyboard arrow keys.
> 
> Step 1:  Open an Emacs built from the current master branch.
> 
> Step 2:  Got to the scratch buffer and evaluate the code below.
> 
> Step 3:  Maneuver up and down with the arrow keys navigating the code below.  The fringe bitmap indicator should track the vertical cursor position, but it does not work.

Does it update if you type "M-x"?  If it does, you aren't triggering a
thorough enough redisplay.

bug#29198: Cursor fringe arrow indicator not updating.

[Keith David Bershatsky]

Yes, "M-x" triggers an immediate removal of the old indicator and places the new indicator at the current line position.

I would recommend adding an exception to the redisplay optimization to check for a change of placement to the built-in overlay fringe arrow indicator.  Since the fringe arrow indicator has been an existing feature of Emacs for quite some time (built-in to xdisp.c), it should (in my opinion) work out of the box without the need for the user to force a redisplay with additional Lisp code.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [11-07-2017 12:37:43] <07 Nov 2017 22:37:43 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> * * *
> 
> Does it update if you type "M-x"?  If it does, you aren't triggering a
> thorough enough redisplay.

bug#29198: Cursor fringe arrow indicator not updating.

[Eli Zaretskii]

> Date:  Tue, 07 Nov 2017 12:48:35 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  29198@debbugs.gnu.org
> 
> Yes, "M-x" triggers an immediate removal of the old indicator and places the new indicator at the current line position.
> 
> I would recommend adding an exception to the redisplay optimization to check for a change of placement to the built-in overlay fringe arrow indicator.  Since the fringe arrow indicator has been an existing feature of Emacs for quite some time (built-in to xdisp.c), it should (in my opinion) work out of the box without the need for the user to force a redisplay with additional Lisp code.

The other features which display the fringe arrow work correctly, so
evidently there is a way of moving it from Lisp.

bug#29198: Cursor fringe arrow indicator not updating.

[Keith David Bershatsky]

This feature was broken on February 23, 2017 with:

dee8674414fae2323fd9cbf05aa762e72fa575e5

I manually reversed the optimization that was applied with the above-mentioned patch, and built a new Emacs 26 downloaded today and am able to verify that this corrects the problem.  I.e., manually reversing *a575e5 as applied to xdisp.c makes everything work properly.

I used the lo-tech approach of trying out various builds until I found the date where the feature stopped working properly.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [11-07-2017 19:39:14] <08 Nov 2017 05:39:14 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> * * *
> 
> The other features which display the fringe arrow work correctly, so
> evidently there is a way of moving it from Lisp.

bug#29198: Cursor fringe arrow indicator not updating.

[Eli Zaretskii]

> Date:  Wed, 08 Nov 2017 20:26:16 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  29198@debbugs.gnu.org
> 
> This feature was broken on February 23, 2017 with:
> 
> dee8674414fae2323fd9cbf05aa762e72fa575e5
> 
> I manually reversed the optimization that was applied with the above-mentioned patch, and built a new Emacs 26 downloaded today and am able to verify that this corrects the problem.  I.e., manually reversing *a575e5 as applied to xdisp.c makes everything work properly.

Thanks.  Meanwhile I also arrived at the conclusion that this is a
bug, because the same recipe does work on TTY frames.

Of course, reverting the above changes is not the solution, because as
you yourself noticed, it caused redisplay to be significantly
snappier.  The problem with those changes is that they opened the path
for the code to use redisplay optimizations when overlay-arrows are
displayed, which (the optimizations) are incompatible with
overlay-arrow display.  So the correct solution would be to disable
those optimizations when overlay-arrows are displayed in the buffer.
Which I just did.

Thanks.

bug#29198: Cursor fringe arrow indicator not updating.

[Keith David Bershatsky]

I thought it may also be helpful for you to be aware that the slow-down that I reported on reddit with this feature was experienced with a build of Emacs _prior_ to February 23, 2017, when the following patch was applied dee8674414fae2323fd9cbf05aa762e72fa575e5.  [I am doing my Emacs C tinkering/development of new features and my daily workflow with an older version of Emacs master branch, that has certain patches applied such as line numbers and horizontal scrolling of the current line.]

Here is the relevent reddit thread from a few weeks ago:

https://www.reddit.com/r/emacs/comments/76a5nu/how_to_speed_up_fringe_overlay_cursor_arrow/dohj50i/?st=j9rzd34c&sh=f19a1d88

I did some profiling (in a version of Emacs prior to February 23, 2017) and can see that there is increased garbage collection, perhaps due to the placement of a marker, but I'm just guessing as to the cause.  It may have also been due to a full redisplay or something of that nature.

Keith

bug#29198: Cursor fringe arrow indicator not updating.

[Keith David Bershatsky]

Thank you, Eli.

I have tested the patch with a current version of Emacs 26 branch and am able to verify that this feature is working well, and the prior issue with the lag has been rectified.

Great job!

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [11-09-2017 08:29:14] <09 Nov 2017 18:29:14 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> * * *
> 
> Thanks.  Meanwhile I also arrived at the conclusion that this is a
> bug, because the same recipe does work on TTY frames.
> 
> Of course, reverting the above changes is not the solution, because as
> you yourself noticed, it caused redisplay to be significantly
> snappier.  The problem with those changes is that they opened the path
> for the code to use redisplay optimizations when overlay-arrows are
> displayed, which (the optimizations) are incompatible with
> overlay-arrow display.  So the correct solution would be to disable
> those optimizations when overlay-arrows are displayed in the buffer.
> Which I just did.
> 
> Thanks.