* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer @ 2016-05-18 13:27 Stephen Berman 2016-05-26 16:09 ` Stephen Berman 0 siblings, 1 reply; 15+ messages in thread From: Stephen Berman @ 2016-05-18 13:27 UTC (permalink / raw) To: 23571 Clicking mouse-1 in a Gnus Article buffer, then releasing it and moving the mouse (without holding down a mouse key) highlights a region, just as when the mouse is dragged with mouse-1 held down. To reproduce: 0. emacs -Q 1. M-x gnus, type `y' at the prompt, then type `B RET news.gmane.org RET 1 RET' to open the most recent article in gmane.announce on the news.gmane.org server. 2. Click anywhere in the Article buffer (except on the texts following the From: and To: headers, which are buttons) with mouse-1, release mouse-1, move the mouse. => A region is highlighted. Subsequently clicking and releasing mouse-1 does not deactivate the mark (but clicking with mouse-2 or mouse-3 does). I have not observed this behavior anywhere besides Gnus Article buffers. This happens in master but not in emacs-25. It happens at least since commit 62d7acae7405732268713006d839a5c3507b9482, which was my first build from master after a long pause, so I don't know when this behavior first appeared (I didn't save any earlier builds from master, which were from many months before, but I'm sure they didn't show this behavior). In GNU Emacs 25.1.50.4 (x86_64-suse-linux-gnu, GTK+ Version 3.14.15) of 2016-05-17 built on rosalinde Repository revision: 631ca55c6decccca2dc0961dc28962819eacc35b Windowing system distributor 'The X.Org Foundation', version 11.0.11601000 System Description: openSUSE 13.2 (Harlequin) (x86_64) Configured using: 'configure --with-xwidgets 'CFLAGS=-Og -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XWIDGETS Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-05-18 13:27 bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer Stephen Berman @ 2016-05-26 16:09 ` Stephen Berman 2016-05-26 16:37 ` Eli Zaretskii 2016-06-10 17:18 ` Stefan Monnier 0 siblings, 2 replies; 15+ messages in thread From: Stephen Berman @ 2016-05-26 16:09 UTC (permalink / raw) To: 23571 On Wed, 18 May 2016 15:27:23 +0200 Stephen Berman <stephen.berman@gmx.net> wrote: > Clicking mouse-1 in a Gnus Article buffer, then releasing it and moving > the mouse (without holding down a mouse key) highlights a region, just > as when the mouse is dragged with mouse-1 held down. To reproduce: > > 0. emacs -Q > 1. M-x gnus, type `y' at the prompt, then type `B RET news.gmane.org RET > 1 RET' to open the most recent article in gmane.announce on the > news.gmane.org server. > 2. Click anywhere in the Article buffer (except on the texts following > the From: and To: headers, which are buttons) with mouse-1, release > mouse-1, move the mouse. > => A region is highlighted. > > Subsequently clicking and releasing mouse-1 does not deactivate the > mark (but clicking with mouse-2 or mouse-3 does). > > I have not observed this behavior anywhere besides Gnus Article buffers. > > This happens in master but not in emacs-25. It happens at least since > commit 62d7acae7405732268713006d839a5c3507b9482, which was my first > build from master after a long pause, so I don't know when this behavior > first appeared (I didn't save any earlier builds from master, which were > from many months before, but I'm sure they didn't show this behavior). Git bisect says: 72166f2f3dba18f1217c666574032f5a0351ed65 is the first bad commit commit 72166f2f3dba18f1217c666574032f5a0351ed65 Author: Martin Rudalics <rudalics@gmx.at> Date: Tue May 3 08:38:49 2016 +0200 Bind `widget-button-click' to mouse-1/-2 instead of down-mouse-1/-2 * lisp/wid-edit.el (widget-keymap): Bind `widget-button-click' to mouse-1/-2 instead of down-mouse-1/-2. Suggested by Stefan Monnier. (Bug#19185, Bug#20398) And indeed, when I execute the above recipe on a build from the commit immediate prior to the above, namely: commit 3a21ea15aecf7af8237c53dfafdc07650a09be3f Author: Lee Bochicchio <lboc.home@gmail.com> Date: Tue May 3 00:12:53 2016 +0200 Add more abbrev tests * test/lisp/abbrev-tests.el (clear-abbrev-table-test): Use `abbrev-expansion' (abbrev-table-empty-p-test, list-abbrevs-test) (prepare-abbrev-list-buffer-test, insert-abbrevs-test) (edit-abbrevs-test, define-abbrevs-test) (read-write-abbrev-file-test) (abbrev-edit-save-to-file-test): New tests (bug#23139). I do not observe the problem with mouse-1 in a Gnus Article buffer. Steve Berman ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-05-26 16:09 ` Stephen Berman @ 2016-05-26 16:37 ` Eli Zaretskii 2016-05-27 9:20 ` Stephen Berman 2016-06-06 19:38 ` Stephen Berman 2016-06-10 17:18 ` Stefan Monnier 1 sibling, 2 replies; 15+ messages in thread From: Eli Zaretskii @ 2016-05-26 16:37 UTC (permalink / raw) To: Stephen Berman; +Cc: 23571 > From: Stephen Berman <stephen.berman@gmx.net> > Date: Thu, 26 May 2016 18:09:56 +0200 > > On Wed, 18 May 2016 15:27:23 +0200 Stephen Berman <stephen.berman@gmx.net> wrote: > > > Clicking mouse-1 in a Gnus Article buffer, then releasing it and moving > > the mouse (without holding down a mouse key) highlights a region, just > > as when the mouse is dragged with mouse-1 held down. To reproduce: > > > > 0. emacs -Q > > 1. M-x gnus, type `y' at the prompt, then type `B RET news.gmane.org RET > > 1 RET' to open the most recent article in gmane.announce on the > > news.gmane.org server. > > 2. Click anywhere in the Article buffer (except on the texts following > > the From: and To: headers, which are buttons) with mouse-1, release > > mouse-1, move the mouse. > > => A region is highlighted. > > > > Subsequently clicking and releasing mouse-1 does not deactivate the > > mark (but clicking with mouse-2 or mouse-3 does). > > > > I have not observed this behavior anywhere besides Gnus Article buffers. > > > > This happens in master but not in emacs-25. It happens at least since > > commit 62d7acae7405732268713006d839a5c3507b9482, which was my first > > build from master after a long pause, so I don't know when this behavior > > first appeared (I didn't save any earlier builds from master, which were > > from many months before, but I'm sure they didn't show this behavior). > > Git bisect says: > > 72166f2f3dba18f1217c666574032f5a0351ed65 is the first bad commit > commit 72166f2f3dba18f1217c666574032f5a0351ed65 > Author: Martin Rudalics <rudalics@gmx.at> > Date: Tue May 3 08:38:49 2016 +0200 > > Bind `widget-button-click' to mouse-1/-2 instead of down-mouse-1/-2 > > * lisp/wid-edit.el (widget-keymap): Bind `widget-button-click' > to mouse-1/-2 instead of down-mouse-1/-2. Suggested by Stefan > Monnier. (Bug#19185, Bug#20398) So I guess Gnus needs to do something to countermand the low-level change, right? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-05-26 16:37 ` Eli Zaretskii @ 2016-05-27 9:20 ` Stephen Berman 2016-06-06 19:38 ` Stephen Berman 1 sibling, 0 replies; 15+ messages in thread From: Stephen Berman @ 2016-05-27 9:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 23571 On Thu, 26 May 2016 19:37:52 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stephen Berman <stephen.berman@gmx.net> >> Date: Thu, 26 May 2016 18:09:56 +0200 >> >> On Wed, 18 May 2016 15:27:23 +0200 Stephen Berman <stephen.berman@gmx.net> wrote: >> >> > Clicking mouse-1 in a Gnus Article buffer, then releasing it and moving >> > the mouse (without holding down a mouse key) highlights a region, just >> > as when the mouse is dragged with mouse-1 held down. To reproduce: >> > >> > 0. emacs -Q >> > 1. M-x gnus, type `y' at the prompt, then type `B RET news.gmane.org RET >> > 1 RET' to open the most recent article in gmane.announce on the >> > news.gmane.org server. >> > 2. Click anywhere in the Article buffer (except on the texts following >> > the From: and To: headers, which are buttons) with mouse-1, release >> > mouse-1, move the mouse. >> > => A region is highlighted. >> > >> > Subsequently clicking and releasing mouse-1 does not deactivate the >> > mark (but clicking with mouse-2 or mouse-3 does). >> > >> > I have not observed this behavior anywhere besides Gnus Article buffers. >> > >> > This happens in master but not in emacs-25. It happens at least since >> > commit 62d7acae7405732268713006d839a5c3507b9482, which was my first >> > build from master after a long pause, so I don't know when this behavior >> > first appeared (I didn't save any earlier builds from master, which were >> > from many months before, but I'm sure they didn't show this behavior). >> >> Git bisect says: >> >> 72166f2f3dba18f1217c666574032f5a0351ed65 is the first bad commit >> commit 72166f2f3dba18f1217c666574032f5a0351ed65 >> Author: Martin Rudalics <rudalics@gmx.at> >> Date: Tue May 3 08:38:49 2016 +0200 >> >> Bind `widget-button-click' to mouse-1/-2 instead of down-mouse-1/-2 >> >> * lisp/wid-edit.el (widget-keymap): Bind `widget-button-click' >> to mouse-1/-2 instead of down-mouse-1/-2. Suggested by Stefan >> Monnier. (Bug#19185, Bug#20398) > > So I guess Gnus needs to do something to countermand the low-level > change, right? I experimented a bit. The problem disappears by not making widget-keymap the parent of gnus-article-mode-map but instead putting the widget bindings directly into gnus-article-mode-map, reverting the problematic bindings: diff --git a/lisp/gnus/gnus-art.el b/lisp/gnus/gnus-art.el index c103e1c..9a64102 100644 --- a/lisp/gnus/gnus-art.el +++ b/lisp/gnus/gnus-art.el @@ -4363,9 +4363,21 @@ article-verify-cancel-lock (put 'gnus-article-mode 'mode-class 'special) -(set-keymap-parent gnus-article-mode-map widget-keymap) +;; (set-keymap-parent gnus-article-mode-map widget-keymap) +(put 'widget-backward :advertised-binding [(shift tab)]) (gnus-define-keys gnus-article-mode-map + ;; Bindings from widget-keymap (but using down-mouse-{1,2} + ;; instead mouse-{1,2} to avoid bug#23571). + "\t" widget-forward + "\e\t" widget-backward + [(shift tab)] widget-backward + [backtab] widget-backward + [down-mouse-2] widget-button-click + [down-mouse-1] widget-button-click + ;; The following definition needs to avoid using escape sequences that + ;; might get converted to ^M when building loaddefs.el + [(control ?m)] widget-button-press + " " gnus-article-goto-next-page [?\S-\ ] gnus-article-goto-prev-page "\177" gnus-article-goto-prev-page I also tried keeping widget-keymap as the parent and just changing the problematic bindings: diff --git a/lisp/gnus/gnus-art.el b/lisp/gnus/gnus-art.el index c103e1c..6b25fcd 100644 --- a/lisp/gnus/gnus-art.el +++ b/lisp/gnus/gnus-art.el @@ -4366,6 +4366,13 @@ article-verify-cancel-lock (set-keymap-parent gnus-article-mode-map widget-keymap) (gnus-define-keys gnus-article-mode-map + ;; Suppress these two bindings from widget-keymap... + [mouse-2] ignore + [mouse-1] ignore + ;; ... and use down-mouse-{1,2} instead to avoid bug#23571. + [down-mouse-2] widget-button-click + [down-mouse-1] widget-button-click + " " gnus-article-goto-next-page [?\S-\ ] gnus-article-goto-prev-page "\177" gnus-article-goto-prev-page This also fixes the problem I observed with mouse-1; however, clicking on an email address with mouse-1 not only correctly opens a message buffer to compose an email to that address, but also incorrectly inserts the most recent item in the desktop clipboard (or primary selection?) at point in that buffer. In contrast, mouse-2 DTRT here. Steve Berman ^ permalink raw reply related [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-05-26 16:37 ` Eli Zaretskii 2016-05-27 9:20 ` Stephen Berman @ 2016-06-06 19:38 ` Stephen Berman 2016-06-07 2:31 ` Eli Zaretskii 1 sibling, 1 reply; 15+ messages in thread From: Stephen Berman @ 2016-06-06 19:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 23571 On Thu, 26 May 2016 19:37:52 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stephen Berman <stephen.berman@gmx.net> >> Date: Thu, 26 May 2016 18:09:56 +0200 >> >> On Wed, 18 May 2016 15:27:23 +0200 Stephen Berman <stephen.berman@gmx.net> wrote: >> >> > Clicking mouse-1 in a Gnus Article buffer, then releasing it and moving >> > the mouse (without holding down a mouse key) highlights a region, just >> > as when the mouse is dragged with mouse-1 held down. To reproduce: >> > >> > 0. emacs -Q >> > 1. M-x gnus, type `y' at the prompt, then type `B RET news.gmane.org RET >> > 1 RET' to open the most recent article in gmane.announce on the >> > news.gmane.org server. >> > 2. Click anywhere in the Article buffer (except on the texts following >> > the From: and To: headers, which are buttons) with mouse-1, release >> > mouse-1, move the mouse. >> > => A region is highlighted. >> > >> > Subsequently clicking and releasing mouse-1 does not deactivate the >> > mark (but clicking with mouse-2 or mouse-3 does). >> > >> > I have not observed this behavior anywhere besides Gnus Article buffers. >> > >> > This happens in master but not in emacs-25. It happens at least since >> > commit 62d7acae7405732268713006d839a5c3507b9482, which was my first >> > build from master after a long pause, so I don't know when this behavior >> > first appeared (I didn't save any earlier builds from master, which were >> > from many months before, but I'm sure they didn't show this behavior). >> >> Git bisect says: >> >> 72166f2f3dba18f1217c666574032f5a0351ed65 is the first bad commit >> commit 72166f2f3dba18f1217c666574032f5a0351ed65 >> Author: Martin Rudalics <rudalics@gmx.at> >> Date: Tue May 3 08:38:49 2016 +0200 >> >> Bind `widget-button-click' to mouse-1/-2 instead of down-mouse-1/-2 >> >> * lisp/wid-edit.el (widget-keymap): Bind `widget-button-click' >> to mouse-1/-2 instead of down-mouse-1/-2. Suggested by Stefan >> Monnier. (Bug#19185, Bug#20398) > > So I guess Gnus needs to do something to countermand the low-level > change, right? It turns out it's not just Gnus Article buffers (as presciently suggested by the title of bug#23653, which I merged with this one): in fact, the same problem appears to happen in all packages in which buffers use widget-keymap; there are quite a few of these, as rgrepping for widget-keymap on the lisp directory shows, and in all that I tried (cus-edit, wid-browse, recentf, printing, secrets, image-dired, todo-mode) the problem with mouse-1 occurred. So I think the fix should be in widget-button-click, or somewhere at that level, and not in all of its users. Steve Berman ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-06-06 19:38 ` Stephen Berman @ 2016-06-07 2:31 ` Eli Zaretskii 2016-06-07 9:05 ` Stephen Berman 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2016-06-07 2:31 UTC (permalink / raw) To: Stephen Berman; +Cc: 23571 > From: Stephen Berman <stephen.berman@gmx.net> > Cc: 23571@debbugs.gnu.org > Date: Mon, 06 Jun 2016 21:38:02 +0200 > > >> 72166f2f3dba18f1217c666574032f5a0351ed65 is the first bad commit > >> commit 72166f2f3dba18f1217c666574032f5a0351ed65 > >> Author: Martin Rudalics <rudalics@gmx.at> > >> Date: Tue May 3 08:38:49 2016 +0200 > >> > >> Bind `widget-button-click' to mouse-1/-2 instead of down-mouse-1/-2 > >> > >> * lisp/wid-edit.el (widget-keymap): Bind `widget-button-click' > >> to mouse-1/-2 instead of down-mouse-1/-2. Suggested by Stefan > >> Monnier. (Bug#19185, Bug#20398) > > > > So I guess Gnus needs to do something to countermand the low-level > > change, right? > > It turns out it's not just Gnus Article buffers (as presciently > suggested by the title of bug#23653, which I merged with this one): in > fact, the same problem appears to happen in all packages in which > buffers use widget-keymap; there are quite a few of these, as rgrepping > for widget-keymap on the lisp directory shows, and in all that I tried > (cus-edit, wid-browse, recentf, printing, secrets, image-dired, > todo-mode) the problem with mouse-1 occurred. So I think the fix should > be in widget-button-click, or somewhere at that level, and not in all of > its users. How do you do that without reintroducing the bug referenced in the above commit's log message? ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-06-07 2:31 ` Eli Zaretskii @ 2016-06-07 9:05 ` Stephen Berman 2016-06-07 15:03 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: Stephen Berman @ 2016-06-07 9:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 23571 On Tue, 07 Jun 2016 05:31:34 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stephen Berman <stephen.berman@gmx.net> >> Cc: 23571@debbugs.gnu.org >> Date: Mon, 06 Jun 2016 21:38:02 +0200 >> >> >> 72166f2f3dba18f1217c666574032f5a0351ed65 is the first bad commit >> >> commit 72166f2f3dba18f1217c666574032f5a0351ed65 >> >> Author: Martin Rudalics <rudalics@gmx.at> >> >> Date: Tue May 3 08:38:49 2016 +0200 >> >> >> >> Bind `widget-button-click' to mouse-1/-2 instead of down-mouse-1/-2 >> >> >> >> * lisp/wid-edit.el (widget-keymap): Bind `widget-button-click' >> >> to mouse-1/-2 instead of down-mouse-1/-2. Suggested by Stefan >> >> Monnier. (Bug#19185, Bug#20398) >> > >> > So I guess Gnus needs to do something to countermand the low-level >> > change, right? >> >> It turns out it's not just Gnus Article buffers (as presciently >> suggested by the title of bug#23653, which I merged with this one): in >> fact, the same problem appears to happen in all packages in which >> buffers use widget-keymap; there are quite a few of these, as rgrepping >> for widget-keymap on the lisp directory shows, and in all that I tried >> (cus-edit, wid-browse, recentf, printing, secrets, image-dired, >> todo-mode) the problem with mouse-1 occurred. So I think the fix should >> be in widget-button-click, or somewhere at that level, and not in all of >> its users. > > How do you do that without reintroducing the bug referenced in the > above commit's log message? I went through those two bug reports and I cannot reproduce the problematic cases (bug#19185: mouse-2 running mouse-yank-primary in a Gnus Article buffer; bug#20398: mouse-1 raising error "No selection is available" on links in a Customize buffer) with -Q in current emacs-25, which does not include the above commit. And when I revert that commit in master I also cannot reproduce those problems. So it's not clear to me what that commit is trying to fix. Steve Berman ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-06-07 9:05 ` Stephen Berman @ 2016-06-07 15:03 ` Eli Zaretskii 2016-06-08 6:34 ` martin rudalics 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2016-06-07 15:03 UTC (permalink / raw) To: Stephen Berman, martin rudalics; +Cc: 23571 > From: Stephen Berman <stephen.berman@gmx.net> > Cc: 23571@debbugs.gnu.org > Date: Tue, 07 Jun 2016 11:05:29 +0200 > > On Tue, 07 Jun 2016 05:31:34 +0300 Eli Zaretskii <eliz@gnu.org> wrote: > > >> From: Stephen Berman <stephen.berman@gmx.net> > >> Cc: 23571@debbugs.gnu.org > >> Date: Mon, 06 Jun 2016 21:38:02 +0200 > >> > >> >> 72166f2f3dba18f1217c666574032f5a0351ed65 is the first bad commit > >> >> commit 72166f2f3dba18f1217c666574032f5a0351ed65 > >> >> Author: Martin Rudalics <rudalics@gmx.at> > >> >> Date: Tue May 3 08:38:49 2016 +0200 > >> >> > >> >> Bind `widget-button-click' to mouse-1/-2 instead of down-mouse-1/-2 > >> >> > >> >> * lisp/wid-edit.el (widget-keymap): Bind `widget-button-click' > >> >> to mouse-1/-2 instead of down-mouse-1/-2. Suggested by Stefan > >> >> Monnier. (Bug#19185, Bug#20398) > >> > > >> > So I guess Gnus needs to do something to countermand the low-level > >> > change, right? > >> > >> It turns out it's not just Gnus Article buffers (as presciently > >> suggested by the title of bug#23653, which I merged with this one): in > >> fact, the same problem appears to happen in all packages in which > >> buffers use widget-keymap; there are quite a few of these, as rgrepping > >> for widget-keymap on the lisp directory shows, and in all that I tried > >> (cus-edit, wid-browse, recentf, printing, secrets, image-dired, > >> todo-mode) the problem with mouse-1 occurred. So I think the fix should > >> be in widget-button-click, or somewhere at that level, and not in all of > >> its users. > > > > How do you do that without reintroducing the bug referenced in the > > above commit's log message? > > I went through those two bug reports and I cannot reproduce the > problematic cases (bug#19185: mouse-2 running mouse-yank-primary in a > Gnus Article buffer; bug#20398: mouse-1 raising error "No selection is > available" on links in a Customize buffer) with -Q in current emacs-25, > which does not include the above commit. And when I revert that commit > in master I also cannot reproduce those problems. So it's not clear to > me what that commit is trying to fix. I hope Martin will be able to help us answer that question. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-06-07 15:03 ` Eli Zaretskii @ 2016-06-08 6:34 ` martin rudalics 2016-06-08 16:42 ` Eli Zaretskii 0 siblings, 1 reply; 15+ messages in thread From: martin rudalics @ 2016-06-08 6:34 UTC (permalink / raw) To: Eli Zaretskii, Stephen Berman; +Cc: 23571 > I hope Martin will be able to help us answer that question. Hardly (I would have chimed into this discussion earlier if I had any good idea). I suppose that the root problem causing these two bugs was solved elsewhere - but bisecting this is too hard for me. Maybe it would be best to revert my "fix" and just wait ... martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-06-08 6:34 ` martin rudalics @ 2016-06-08 16:42 ` Eli Zaretskii 2016-06-09 8:39 ` martin rudalics 0 siblings, 1 reply; 15+ messages in thread From: Eli Zaretskii @ 2016-06-08 16:42 UTC (permalink / raw) To: martin rudalics; +Cc: stephen.berman, 23571 > Date: Wed, 08 Jun 2016 08:34:25 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: 23571@debbugs.gnu.org > > > I hope Martin will be able to help us answer that question. > > Hardly (I would have chimed into this discussion earlier if I had any > good idea). I suppose that the root problem causing these two bugs was > solved elsewhere - but bisecting this is too hard for me. Maybe it > would be best to revert my "fix" and just wait ... I'm okay with reverting on master, but not on the release branch. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-06-08 16:42 ` Eli Zaretskii @ 2016-06-09 8:39 ` martin rudalics 2016-06-09 9:00 ` Stephen Berman 0 siblings, 1 reply; 15+ messages in thread From: martin rudalics @ 2016-06-09 8:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: stephen.berman, 23571 >> ... revert my "fix" and just wait ... > > I'm okay with reverting on master, but not on the release branch. Stephen, what would you prefer? martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-06-09 8:39 ` martin rudalics @ 2016-06-09 9:00 ` Stephen Berman 2016-06-10 7:15 ` martin rudalics 0 siblings, 1 reply; 15+ messages in thread From: Stephen Berman @ 2016-06-09 9:00 UTC (permalink / raw) To: martin rudalics; +Cc: 23571 On Thu, 09 Jun 2016 10:39:08 +0200 martin rudalics <rudalics@gmx.at> wrote: >>> ... revert my "fix" and just wait ... >> >> I'm okay with reverting on master, but not on the release branch. > > Stephen, what would you prefer? AFAIK the commit is not present on emacs-25, but I would prefer to have it reverted on master, since its effect is a frequent annoyance for me and, as I noted, even without it I could not reproduce the bugs I understand it was intended to fix; but if I'm mistaken about that, we should find out soon enough and hopefully could then zero in on the problem. Steve Berman ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-06-09 9:00 ` Stephen Berman @ 2016-06-10 7:15 ` martin rudalics 2018-04-12 16:04 ` Lars Ingebrigtsen 0 siblings, 1 reply; 15+ messages in thread From: martin rudalics @ 2016-06-10 7:15 UTC (permalink / raw) To: Stephen Berman; +Cc: 23571 > AFAIK the commit is not present on emacs-25, but I would prefer to have > it reverted on master, since its effect is a frequent annoyance for me > and, as I noted, even without it I could not reproduce the bugs I > understand it was intended to fix; but if I'm mistaken about that, we > should find out soon enough and hopefully could then zero in on the > problem. I've reverted that commit now. martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-06-10 7:15 ` martin rudalics @ 2018-04-12 16:04 ` Lars Ingebrigtsen 0 siblings, 0 replies; 15+ messages in thread From: Lars Ingebrigtsen @ 2018-04-12 16:04 UTC (permalink / raw) To: martin rudalics; +Cc: Stephen Berman, 23571 martin rudalics <rudalics@gmx.at> writes: >> AFAIK the commit is not present on emacs-25, but I would prefer to have >> it reverted on master, since its effect is a frequent annoyance for me >> and, as I noted, even without it I could not reproduce the bugs I >> understand it was intended to fix; but if I'm mistaken about that, we >> should find out soon enough and hopefully could then zero in on the >> problem. > > I've reverted that commit now. Ok; closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer 2016-05-26 16:09 ` Stephen Berman 2016-05-26 16:37 ` Eli Zaretskii @ 2016-06-10 17:18 ` Stefan Monnier 1 sibling, 0 replies; 15+ messages in thread From: Stefan Monnier @ 2016-06-10 17:18 UTC (permalink / raw) To: Stephen Berman; +Cc: 23571 > * lisp/wid-edit.el (widget-keymap): Bind `widget-button-click' > to mouse-1/-2 instead of down-mouse-1/-2. Suggested by Stefan > Monnier. (Bug#19185, Bug#20398) FWIW, I'm not surprised it introduces problems. I do think it (or something like it) is a desirable change, but it requires further changes. Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-04-12 16:04 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-05-18 13:27 bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer Stephen Berman 2016-05-26 16:09 ` Stephen Berman 2016-05-26 16:37 ` Eli Zaretskii 2016-05-27 9:20 ` Stephen Berman 2016-06-06 19:38 ` Stephen Berman 2016-06-07 2:31 ` Eli Zaretskii 2016-06-07 9:05 ` Stephen Berman 2016-06-07 15:03 ` Eli Zaretskii 2016-06-08 6:34 ` martin rudalics 2016-06-08 16:42 ` Eli Zaretskii 2016-06-09 8:39 ` martin rudalics 2016-06-09 9:00 ` Stephen Berman 2016-06-10 7:15 ` martin rudalics 2018-04-12 16:04 ` Lars Ingebrigtsen 2016-06-10 17:18 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).