[Top][All Lists]

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

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

From: Toby Cubitt
Subject: bug#459: Zero-length overlays, overlay keymaps, and `overlays-at'
Date: Sun, 22 Jun 2008 12:31:48 +0100
User-agent: Thunderbird (X11/20080508)

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 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.

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

reply via email to

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