* 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-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
* 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
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).