emacs-devel
[Top][All Lists]
Advanced

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

Re: Bug#142608: emacs21: please apply flyspell patch from preview-latex


From: David Kastrup
Subject: Re: Bug#142608: emacs21: please apply flyspell patch from preview-latex package
Date: 17 Apr 2002 23:36:03 +0200

Richard Stallman <address@hidden> writes:

>     fixed for perhaps half a year now (and still has), I would really be
>     surprised if the fixes (or their supersession by larger changes taking
>     them into account) would not already be present in RC.
> 
> Mere passage of time does not put anything into RC.
> (How could it?)  That happens only under human control.
> That is why I suggested you put these into RC.
> 
>       IIRC, 21.3 was
>     not supposed to be mere bug fixes as compared to 21.2, was it?
> 
> We have decided to base 21.3 on RC.  The release from HEAD
> will be 21.4.
> 
>     I would first have to get developer access to GNU Emacs, I am
>     registered as "dak" at Savannah and have signed all the necessary
>     papers.
> 
> Eli, can you do that?

I have now verified that indeed flyspell.el and mouse-drag.el do not
contain any fixes to the annoying behavior.  The problem in both of
those cases was that the implemented behavior of the packages stole
mouse-click events on overlays with a keymap property.

The change for flyspell.el is minimally invasive: it just removes the
keybinding causing the problem (the function called would check
whether the click was on the flyspell overlay and call the appropriate
handler if it was, and the local keymap if it wasn't, ignoring any
overlay maps that might actually have priority).  While this
superficially looks like this would stop flyspell's use of the mouse
button itself, this is not the case: flyspell itself uses a keymap on
its overlay, and that functions cleably.  I can only guess that there
must have been some point of time where this did not work reliably,
and thus the local keymap was employed as well, leading to the
problem that when flyspell.el decided it did not really need to treat
the click, it passed it to the wrong handler.

I believe that quite more was changed in HEAD as a result of my report
at the time.  The patch from me is rather small and has tested well.

The change in mouse-drag.el is more thorough: again we have a package
that takes control over an event and then decides whether it will use
the event itself, or pass it on.  Again, this decision is done wrong
as it does not take clicks on overlays into account.  In this case,
the solution was a bit more complicated, but still is shorter than
the original version: I push the event back into the event queue
(after doing the changes to it that mouse-drag does, too) and let
Emacs' event handler figure out what to do instead of trying to
second-guess it.

Both patches have been used for some time by me and appear safe.  I
include them here again and would be glad if they made it into RC:
both have been reported several times as a bug for preview-latex.

I would also be glad to apply them myself if you gave me developer
access.

Attachment: flyspell.patch
Description: Make flyspell.el not unnecessarily steal events

Attachment: mouse-drag.patch
Description: Make mouse-drag pass events on correctly


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: address@hidden

reply via email to

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