[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22762: 25.1.50; Enhancement/Feature Request: window-local `overlay_a

From: Keith David Bershatsky
Subject: bug#22762: 25.1.50; Enhancement/Feature Request: window-local `overlay_arrow_variable_list`
Date: Mon, 22 Feb 2016 10:36:04 -0800

Because the cursor position remains anchored at a previous position in a 
non-selected window, my preference would be that the bitmap either remains 
where it is in the non-selected window OR that it completely disappear until 
the window is selected again.  After evaluating the following example, I move 
the cursor upwards or downwards with the arrow key and find myself visually 
distracted by the bitmap moving in the non-selected window -- especially 
knowing that the cursor is anchored at a different position in that 
non-selected window.  When I switch to the non-selected window, the bitmap 
jumps back to where the cursor was previously anchored.

I like the feature of the `overlay-arrow-variable-list`, but find myself 
leaning towards using a plain overlay in the fringe with the 'window property 
to avoid the above-described visual distraction.

(add-to-list 'overlay-arrow-variable-list  'hello-world-symbol-triangle)

(put 'hello-world-symbol-triangle 'overlay-arrow-bitmap 'right-triangle)

(defun my-set-position ()
  (let* (
      (pbol (point-at-bol))
      (my-point-marker (point-marker)) )
    (setq hello-world-symbol-triangle
          (copy-marker pbol))))))

(add-hook 'post-command-hook 'my-set-position nil t)

(switch-to-buffer-other-window (current-buffer))


At Mon, 22 Feb 2016 17:59:45 +0200,
Eli Zaretskii wrote:
>  * * *
> I'm not sure I understand the use case.  Could you please describe a
> sequence of steps that lead to the confusing display?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]