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

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.2.3-bugs.debian.org_2005_01_02
Received: (at 459) by emacsbugs.donarmstrong.com; 5 Aug 2008 23:05:11 +0000
Received: from cyd (CYD.MIT.EDU [18.115.2.24])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m75N57Wi031504
	for <459 <at> emacsbugs.donarmstrong.com>; Tue, 5 Aug 2008 16:05:09 -0700
Received: by cyd (Postfix, from userid 1000)
	id 279A857E338; Tue,  5 Aug 2008 19:05:35 -0400 (EDT)
From: Chong Yidong <cyd <at> stupidchicken.com>
To: 459 <at> debbugs.gnu.org
Subject: Re: Zero-length overlays, overlay keymaps, and `overlays-at'
Date: Tue, 05 Aug 2008 19:05:35 -0400
Message-ID: <87ej53xdts.fsf <at> stupidchicken.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

> `overlays-at' never returns zero-length overlays.

I think the way to fix this is to add an optional argument to
overlays-at telling it to include zero-length overlays.  However, this
will have to wait till after the release.

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 required=4.0 tests=BAYES_00,FOURLA autolearn=no
	version=3.2.3-bugs.debian.org_2005_01_02
Received: (at 459) by emacsbugs.donarmstrong.com; 22 Jun 2008 11:32:04 +0000
Received: from starfish.geekisp.com (mail.geekisp.com [216.168.135.169])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5MBW0XM032030
	for <459 <at> emacsbugs.donarmstrong.com>; Sun, 22 Jun 2008 04:32:02 -0700
Received: (qmail 20256 invoked by uid 1003); 22 Jun 2008 11:31:55 -0000
Received: from [192.168.2.3] (localhost.geekisp.com [127.0.0.1]) by
	localhost.geekisp.com (tmda-ofmipd) with ESMTP;
	Sun, 22 Jun 2008 07:31:49 -0400
Message-ID: <485E3824.6030405 <at> dr-qubit.org>
Date: Sun, 22 Jun 2008 12:31:48 +0100
User-Agent: Thunderbird 2.0.0.14 (X11/20080508)
MIME-Version: 1.0
To: 459 <at> debbugs.gnu.org
Subject: Re: Zero-length overlays, overlay keymaps, and `overlays-at'
References: <485D204B.2 <at> dr-qubit.org>
In-Reply-To: <485D204B.2 <at> dr-qubit.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Delivery-Agent: TMDA/1.1.11 (Ladyburn)
From: Toby Cubitt <toby-dated-1214566315.0e29e2 <at> dr-qubit.org>
X-Primary-Address: toby <at> dr-qubit.org


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
> 

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-5.0 required=4.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
Received: (at submit) by emacsbugs.donarmstrong.com; 21 Jun 2008 15:38:07 +0000
Received: from lists.gnu.org (lists.gnu.org [199.232.76.165])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5LFc2SL029316
	for <submit <at> emacsbugs.donarmstrong.com>; Sat, 21 Jun 2008 08:38:04 -0700
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KA5A9-0003UR-ET
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 11:38:01 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KA5A5-0003U9-6n
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 11:38:00 -0400
Received: from [199.232.76.173] (port=41256 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43)
	id 1KA5A5-0003U6-2u
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 11:37:57 -0400
Received: from mail.geekisp.com ([216.168.135.169]:15176 helo=starfish.geekisp.com)
	by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60)
	(envelope-from <t.s.cubitt.98 <at> cantab.net>)
	id 1KA5A4-0006cO-G6
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 11:37:57 -0400
Received: (qmail 6244 invoked by uid 1003); 21 Jun 2008 15:37:50 -0000
Received: from [192.168.2.2] (localhost.geekisp.com [127.0.0.1]) by
	localhost.geekisp.com (tmda-ofmipd) with ESMTP;
	Sat, 21 Jun 2008 11:37:48 -0400
Message-ID: <485D204B.2 <at> dr-qubit.org>
Date: Sat, 21 Jun 2008 16:37:47 +0100
User-Agent: Thunderbird 2.0.0.14 (X11/20080508)
MIME-Version: 1.0
To: bug-gnu-emacs <at> gnu.org
Subject: Zero-length overlays, overlay keymaps, and `overlays-at'
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Delivery-Agent: TMDA/1.1.11 (Ladyburn)
From: Toby Cubitt <t.s.cubitt.98 <at> cantab.net>
X-Primary-Address: t.s.cubitt.98 <at> cantab.net
X-detected-kernel: by monty-python.gnu.org: OpenBSD 3.0-3.9


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