From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David.Kastrup@t-online.de (David Kastrup) Newsgroups: gmane.emacs.devel Subject: Re: Bug#142608: emacs21: please apply flyspell patch from preview-latex package Date: 17 Apr 2002 23:36:03 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: References: <871ydiq5ju.fsf@raven.i.defaultvalue.org> <200204152200.g3FM06K23791@aztec.santafe.edu> <200204171604.g3HG4ru24873@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: main.gmane.org 1019079740 12359 127.0.0.1 (17 Apr 2002 21:42:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 17 Apr 2002 21:42:20 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16xxC0-0003DE-00 for ; Wed, 17 Apr 2002 23:42:20 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16xxUs-0005NS-00 for ; Thu, 18 Apr 2002 00:01:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16xxBo-0004EP-00; Wed, 17 Apr 2002 17:42:08 -0400 Original-Received: from mailout05.sul.t-online.com ([194.25.134.82]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16xx90-0003sT-00; Wed, 17 Apr 2002 17:39:14 -0400 Original-Received: from fwd00.sul.t-online.de by mailout05.sul.t-online.com with smtp id 16xx64-0003KW-05; Wed, 17 Apr 2002 23:36:12 +0200 Original-Received: from tupik.goethe.zz (520018396234-0001@[62.226.11.220]) by fwd00.sul.t-online.com with esmtp id 16xx5x-0OvOrIC; Wed, 17 Apr 2002 23:36:05 +0200 Original-Received: (from dak@localhost) by tupik.goethe.zz (8.11.6/linuxconf) id g3HLa3m01575; Wed, 17 Apr 2002 23:36:03 +0200 Original-To: rms@gnu.org In-Reply-To: <200204171604.g3HG4ru24873@aztec.santafe.edu> Original-Lines: 72 X-Sender: 520018396234-0001@t-dialin.net Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2715 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2715 --=-=-= Richard Stallman 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. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=flyspell.patch Content-Description: Make flyspell.el not unnecessarily steal events Apply this patch only if middle-mouse clicks on preview-icons paste instead of toggling when in fly-spell mode. After version 21.2 of Emacs, this should be fixed already. --- /usr/local/emacs-21/share/emacs/21.1/lisp/textmodes/flyspell.el.old Mon Jul 16 14:22:59 2001 +++ /usr/local/emacs-21/share/emacs/21.1/lisp/textmodes/flyspell.el Wed Nov 7 16:18:54 2001 @@ -378,9 +378,7 @@ (setq minor-mode-map-alist (cons (cons 'flyspell-mode flyspell-mode-map) minor-mode-map-alist))) - (define-key flyspell-mode-map "\M-\t" 'flyspell-auto-correct-word) - (define-key flyspell-mode-map [(mouse-2)] - (function flyspell-correct-word/local-keymap))) + (define-key flyspell-mode-map "\M-\t" 'flyspell-auto-correct-word)) ;; the name of the overlay property that defines the keymap --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=mouse-drag.patch Content-Description: Make mouse-drag pass events on correctly Apply this patch only if middle-mouse clicks on preview-icons paste instead of toggling when using mouse-drag mode. After version 21.2 of Emacs, this should be fixed already. --- mouse-drag.el.old Mon Jan 8 20:12:12 2001 +++ mouse-drag.el Tue Nov 13 22:47:36 2001 @@ -208,7 +208,7 @@ (start-col (car (posn-col-row start-posn))) (old-selected-window (selected-window)) event end row mouse-delta scroll-delta - have-scrolled point-event-p old-binding + have-scrolled window-last-row col mouse-col-delta window-last-col (scroll-col-delta 0) @@ -261,18 +261,13 @@ (mouse-drag-safe-scroll scroll-delta scroll-col-delta) (mouse-drag-repeatedly-safe-scroll scroll-delta scroll-col-delta))))) ;xxx ;; If it was a click and not a drag, prepare to pass the event on. - ;; Note: We must determine the pass-through event before restoring - ;; the window, but invoke it after. Sigh. + ;; Is there a more correct way to reconstruct the event? (if (and (not have-scrolled) (mouse-drag-events-are-point-events-p start-posn end)) - (setq point-event-p t - old-binding (key-binding - (vector (event-basic-type start-event))))) + (push (cons (event-basic-type start-event) (cdr start-event)) + unread-command-events)) ;; Now restore the old window. - (select-window old-selected-window) - ;; For clicks, call the old function. - (if point-event-p - (call-interactively old-binding)))) + (select-window old-selected-window))) (defun mouse-drag-drag (start-event) "\"Drag\" the page according to a mouse drag. @@ -297,7 +292,7 @@ (start-col (car (posn-col-row start-posn))) (old-selected-window (selected-window)) event end row mouse-delta scroll-delta - have-scrolled point-event-p old-binding + have-scrolled window-last-row col mouse-col-delta window-last-col (scroll-col-delta 0) @@ -335,18 +330,14 @@ (setq have-scrolled t) (mouse-drag-safe-scroll scroll-delta scroll-col-delta))))))) ;; If it was a click and not a drag, prepare to pass the event on. - ;; Note: We must determine the pass-through event before restoring - ;; the window, but invoke it after. Sigh. + ;; Is there a more correct way to reconstruct the event? (if (and (not have-scrolled) (mouse-drag-events-are-point-events-p start-posn end)) - (setq point-event-p t - old-binding (key-binding - (vector (event-basic-type start-event))))) + (push (cons (event-basic-type start-event) (cdr start-event)) + unread-command-events)) ;; Now restore the old window. - (select-window old-selected-window) - ;; For clicks, call the old function. - (if point-event-p - (call-interactively old-binding)))) + (select-window old-selected-window))) + (provide 'mouse-drag) --=-=-= -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: David.Kastrup@t-online.de --=-=-=--