bug#459: Zero-length overlays, overlay keymaps, and `overlays-at'

[Toby Cubitt]

Looking through NEWS.22, I came upon the following:

*** The `keymap' property now also works at the ends of overlays and
text properties, according to their stickiness.  This also means that it
works with empty overlays.  The same hold for the `local-map' property.

So the first issue I reported is already fixed! (In exactly the way I 
suggested, which makes me suspect that future-bug might now have been 
fixed too... :) However, this behaviour isn't documented in the Emacs 
Lisp manual (unless I've overlooked something yet again), which *is* a bug.


I think the second issue still remains, though.

Toby



Toby Cubitt wrote:
[...]
> 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.
[...]
>
> Suggestions for possible fixes:
> -------------------------------
[...]
> 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.
[...]
>
>
> 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