GNU bug report logs - #459
Zero-length overlays, overlay keymaps, and `overlays-at'

Previous Next

Full log

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Toby Cubitt <t.s.cubitt.98 <at> cantab.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Zero-length overlays, overlay keymaps, and `overlays-at'
Date: Sat, 21 Jun 2008 16:37:47 +0100

Two separate issues involving zero-length overlays. By "zero-length", I 
mean an overlay that starts and ends at the same position. (I'm not 
knowledgeable enough about Emacs' c internals to work it out whether 
these issues are fundamentally related or not.)

Strictly speaking, neither of these issues are bugs, since the behaviour 
is consistent with the documentation. But it makes it difficult or 
impossible to do certain things in Emacs that one would expect to be 
able to do.

Both "bugs" have been present since version 21, including the current 
stable version and in recent CVS (20.0.60.1).


1. Overlay keymaps
==================

"Bug" description:
------------------
When a zero-length overlay has a keymap property, that keymap is never 
active, even if when the point is at the overlay's start (and end) 
position. This makes it impossible in Emacs to define a key binding that 
is only active at a single point in the buffer.


Steps to reproduce:
-------------------
(setq test-overlay (make-overlay 1 1))  ; any position will do
(overlay-put test-overlay 'keymap (make-sparse-keymap))
;; any key binding will do
(define-key (overlay-get test-overlay 'keymap) "a" 'end-of-line)

Move point to position 1. Type "a". The character "a" is inserted 
instead of the point moving to the end of the line.


Impact:
-------
Zero-length overlays are probably rarely used. But it is strange to be 
able to define a keybinding in Emacs that is active at two or more 
neighbouring point positions, but not at a single point position. At the 
very least, this is a missing feature.

When this behaviour *is* needed (as in my completion-UI and 
auto-overlays packages), it is extremely difficult to work-around this 
issue. In fact, it requires abandoning overlay keymaps entirely, and 
simulating this behaviour via minor-mode maps and an ugly hack to check 
for overlays, temporarily disable the minor-mode map if no overlay was 
found, look up the keybinding again, call whatever command it is now 
bound to it, then re-enable the minor-mode map.


Suggestions for possible fixes:
-------------------------------
a) Make overlay keymaps active when the point is at the start, end, or 
within the overlay (currently, it is only active when the next character 
is within the overlay). This seems unlikely to have significant impact 
on other parts of Emacs, since zero-length overlays are rarely used.

b) If a) is undesirable, why not make the behaviour depend on the 
overlay's front-advance and read-advance properties? If the zero-length 
overlay has null front-advance and non-null read-advance, then there is 
some logic in making its keymap active when point is at that position, 
since any character inserted at that point will be within the overlay 
after insertion.

c) Add another overlay property to control the keymap behaviour in the 
case of zero-length overlays. (This seems an ugly solution to me, since 
it involves adding a whole new property just to deal with a very rare 
edge-case.)


2. `overlays-at'
================

"Bug" description:
------------------
`overlays-at' never returns zero-length overlays.


Steps to reproduce:
-------------------
(make-overlay 1 1)  ; any position will do
(overlays-at 1)

Returns nil instead of the overlay from 1 to 1.


Impact:
-------
Again, zero-length overlays are probably rarely used. But this makes it 
impossible in Emacs to find a zero-length overlay using `overlays-at'. 
Instead, one has to work-around this using three calls to `overlays-in' 
then filter out overlays that shouldn't be in the list.

Overlays do fairly frequently become zero-length when the text they 
cover is deleted (depending on their front- and rear-advance 
properties), and this "bug" makes them suddenly disappear from the 
return value of `overlays-at' even though they still exist in the buffer.


Suggestions for possible fixes:
-------------------------------
a) Modify (overlays-at pos) to return zero-length overlays that start at 
pos (it already returns all other overlays that start at pos). Again, 
this seems unlikely to have significant impact on other parts of Emacs, 
since zero-length overlays are rarely used.

b) Modify (overlays-at pos) to return zero-length overlays that start at 
pos, and have a null front-advance and non-nil rear-advance property. 
(The logic for this is the same as in option b) for the overlay keymaps 
issue.)

c) Leave `overlays-at' unchanged, and define a new function 
`overlays-at-point' that implements either a) or b).


Toby Cubitt

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.