GNU bug report logs - #102
keymap property ignored for mouse click on overlay

Previous Next

Full log

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> stupidchicken.com>
Cc: "'Martin Rudalics'" <rudalics <at> gmx.at>, <102 <at> debbugs.gnu.org>
Subject: RE: keymap property ignored for mouse click on overlay
Date: Wed, 16 Apr 2008 11:01:59 -0700

> After studying this some more, I've decided to leave the current
> behavior alone.
> 
> It turns out that the patch I posted earlier doesn't work for
> after-strings, because the buffer position associated with an
> after-string is the end of the overlay (1 + the postition of the last
> character).  As a result, there's no efficient way for 
> read_key_sequence
> to detect the existence of an overlay with a keymap for an 
> after-string.
> 
> The fact that the buffer position of an after-string is the 
> overlay end
> isn't easily changed, because the redisplay engine relies on this for
> efficiency (it means that the redisplay iterator can process all the
> strings at a given charpos, before processing the buffer text).
> 
> Since the benefit of this feature is rather marginal in the 
> first place,
> I think it's better to simply document that display strings don't
> inherit keymaps.  The way to DTRT is to give the display string a
> 'keymap text property, which has always worked.

Could you state how that would change in the test case I sent? I added both a
`display' property and a `keymap' property to the overlay. What would the new
test-case code look like?

I'm OK with documenting a limitation if there is an easy alternative way to do
what I need.

Thx.

Previous Next

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