[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
(cond
((bolp)
my-point-marker)
(t
(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?