bug-gnu-emacs
[Top][All Lists]
Advanced

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

Re: [address@hidden: Re: [Preview-latex-devel] CVS-1.42; scale function]


From: David Kastrup
Subject: Re: [address@hidden: Re: [Preview-latex-devel] CVS-1.42; scale function]
Date: 09 Nov 2001 01:58:29 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

>>>>> "Stefan" == Stefan Monnier <monnier+gnu.emacs.bug/news/@RUM.cs.yale.edu> 
>>>>> writes:

>>>>> "David" == David Kastrup <David.Kastrup@t-online.de> writes:
    >> The mouse-2 feature already gets provided by a 'keymap property
    >> (actually, the 'local-map property since flyspell.el is lacking the
    >> knowledge that Emacs-21 already has the 'keymap property) on the
    >> overlay.  The minor map key binding is there from a time where the
    >> overlay keymaps did not work, and so the entire buffer got overlayed
    >> with a mouse-2 binding that tries to detect whether the mouse is
    >> pressed in an overlay and if not, tries to do what the mousepress
    >> would have done instead.  This fake key action ignores overlay keymaps
    >> and thus destroys my bindings.

    Stefan> Ah, I think you're right.  It probably ends up not taking
    Stefan> the overlay bindings into account.  I'll take a look.
    Stefan> Thank you for that precise description.

    Stefan> As for "why the minor mode map".  It's actually a little
    Stefan> bit more subtle than just historical: the intent is to be
    Stefan> able to type M-TAB even a few chars after the mistyped
    Stefan> word in which case the overlay's `local-map' and `keymap'
    Stefan> are of no help.

I don't mind the key binding, it is the mouse binding that is
unnecessary and gets in the way.  No user will expect to mouse-click way
after the actual overlay and still get a reaction.  As to taking
overlays into account in the simulated code, forget it.  Too
complicated and error-prone, and actually not possible.  When faking the
event, you have no way of distinguishing between
a) a mouse click into a before-string overlay property with a keymap
   in the before-string from a mouse click onto the first character of
   an overlay itself
b) a mouse-click into the after-string overlay property with a keymap
   in the after-string from a mouse click after the last character of
   the overlay

In short, mouse clicks can occur to objects that are not part of the
buffer proper.  I see no way to track them back to the objects in
question once you intercepted the event with your own keymap.

In order to do the proper thing with such an intercepted event, you'd
probably need more primitive Emacs functions.  I would not mind them:
currently, aborting isearch by a mouse-click on an overlay with a
keymap does not work: isearch does a similar interception job and
fails similarly.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de



reply via email to

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