🚀 go-pugleaf

In GNU Emacs 19.22.9 of Tue Jun 21 1994 on rodan.isi.edu (hpux)

In the default global keymap I find in emacs19, the event
down-mouse-1 is bound to the function mouse-drag-region.
This function calls mouse-set-point, which selects the window
in which the mouse down-mouse-1 event occurred and resets point in that
window.  It then starts tracking the mouse.  If it turns out that
the user has just done a mouse-1, but not a mouse drag, it looks
up (using key-binding) the effective binding for mouse-1, and applies
it WITHOUT UNDOING THE CHANGES EFFECTED BY MOUSE-SET-POINT.


I have a mode in which I want to handle mouse clicks myself (at least some
of them) but I want the default behavior for drags.  If I just
put a mouse-1 entry in my mode's keymap, my handler is executed in
a state in which an unwanted side effect has already occurred, from the
global map's down-mouse-1 event.  And, as far as I can see, I don't even
have a way to undo the unwanted side effect, because there is no record
of the previously selected window and value of point.  What I have
done for now is to also handle down-mouse-1 in my mode's keymap, with a 
little function that records the selected window and point and then
calls mouse-drag-region.  This seems convoluted, at best.  I do not see
why my mode's mouse-1 handler should have to contend with side effects that 
were introduced by code that was looking for a drag event that never happened.
[Or else I really have misunderstood your model of mouse events!]


Another minor observation -- The definition of mouse-drag-region in mouse.el
apparently relies on the function it finds from doing key-binding to
return normally -- that is, it does a funcall, and then does a delete-overlay.
If the overlay is not going to be deleted BEFORE the funcall, I imagine you 
want to use unwind-protect to ensure that it gets deleted.

neil