* Mouse-1 behaviour changed in gnus?
@ 2006-01-05 7:28 Piet van Oostrum
2006-01-05 14:30 ` Reiner Steib
2006-01-05 16:30 ` Piet van Oostrum
0 siblings, 2 replies; 9+ messages in thread
From: Piet van Oostrum @ 2006-01-05 7:28 UTC (permalink / raw)
A few days ago (Tuesday) I checked out a new copy from the CVS and installed
it. I noticed one problem and I am not sure if it is a bug, a policy change
or just a matter of a different configuration:
When I click mouse-1 on a link in a gnus *Article* buffer, the link isn't
followed, as in the previous version I had, but the buffer scrolls one
line. Mouse-2 does follow the link. Why is this?
--
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet@vanoostrum.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mouse-1 behaviour changed in gnus?
2006-01-05 7:28 Mouse-1 behaviour changed in gnus? Piet van Oostrum
@ 2006-01-05 14:30 ` Reiner Steib
2006-01-05 21:01 ` Piet van Oostrum
2006-01-05 16:30 ` Piet van Oostrum
1 sibling, 1 reply; 9+ messages in thread
From: Reiner Steib @ 2006-01-05 14:30 UTC (permalink / raw)
Cc: emacs-devel
On Thu, Jan 05 2006, Piet van Oostrum wrote:
> A few days ago (Tuesday) I checked out a new copy from the CVS and installed
> it. I noticed one problem and I am not sure if it is a bug, a policy change
> or just a matter of a different configuration:
Which was the last version where you did _not_ notice this behavior?
I don't recall any relevant changes in Gnus. And there were no
check-ins in lisp/gnus/ at all since 2005-12-16.
> When I click mouse-1 on a link in a gnus *Article* buffer, the link isn't
> followed, as in the previous version I had, but the buffer scrolls one
> line. Mouse-2 does follow the link. Why is this?
Which kind of link?
Some test links follow: http://www.gnu.org (info "(gnus)Article
Buttons") `gnus-button-emacs-level' <reinersteib+gmane@imap.cc>
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mouse-1 behaviour changed in gnus?
2006-01-05 7:28 Mouse-1 behaviour changed in gnus? Piet van Oostrum
2006-01-05 14:30 ` Reiner Steib
@ 2006-01-05 16:30 ` Piet van Oostrum
2006-01-07 12:06 ` public
2006-02-16 21:19 ` Reiner Steib
1 sibling, 2 replies; 9+ messages in thread
From: Piet van Oostrum @ 2006-01-05 16:30 UTC (permalink / raw)
>>>>> Piet van Oostrum <piet@cs.uu.nl> (PvO) wrote:
>PvO> When I click mouse-1 on a link in a gnus *Article* buffer, the link
>PvO> isn't followed, as in the previous version I had, but the buffer
>PvO> scrolls one line. Mouse-2 does follow the link. Why is this?
I found that the problem only occurs when the cursor is not inside the
*Article* buffer. So it probably is related to this change:
2005-12-27 Richard M. Stallman <rms@gnu.org>
* mouse.el (mouse-drag-region-1): When remapping mouse-1 to
mouse-2, go back to previously selected window, so it's selected
when mouse-2 command runs.
I have looked into the code, but it isn't obvious to me what is wrong with
it.
--
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet@vanoostrum.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mouse-1 behaviour changed in gnus?
2006-01-05 14:30 ` Reiner Steib
@ 2006-01-05 21:01 ` Piet van Oostrum
0 siblings, 0 replies; 9+ messages in thread
From: Piet van Oostrum @ 2006-01-05 21:01 UTC (permalink / raw)
>>>>> Reiner Steib <reinersteib+gmane@imap.cc> (RS) wrote:
>RS> On Thu, Jan 05 2006, Piet van Oostrum wrote:
>>> A few days ago (Tuesday) I checked out a new copy from the CVS and installed
>>> it. I noticed one problem and I am not sure if it is a bug, a policy change
>>> or just a matter of a different configuration:
>RS> Which was the last version where you did _not_ notice this behavior?
>RS> I don't recall any relevant changes in Gnus. And there were no
>RS> check-ins in lisp/gnus/ at all since 2005-12-16.
The previous version I had was Oct 28
>>> When I click mouse-1 on a link in a gnus *Article* buffer, the link isn't
>>> followed, as in the previous version I had, but the buffer scrolls one
>>> line. Mouse-2 does follow the link. Why is this?
>RS> Which kind of link?
>RS> Some test links follow: http://www.gnu.org (info "(gnus)Article
>RS> Buttons") `gnus-button-emacs-level' <reinersteib+gmane@imap.cc>
I see 3 links above (gnus-button-emacs-level isn't a link) and all 3 have
this effect. When the cursor is already in the Article buffer it works.
--
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet@vanoostrum.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mouse-1 behaviour changed in gnus?
2006-01-05 16:30 ` Piet van Oostrum
@ 2006-01-07 12:06 ` public
2006-01-11 15:31 ` Piet van Oostrum
2006-02-16 21:19 ` Reiner Steib
1 sibling, 1 reply; 9+ messages in thread
From: public @ 2006-01-07 12:06 UTC (permalink / raw)
Piet van Oostrum <piet@cs.uu.nl> writes:
>>>>>> Piet van Oostrum <piet@cs.uu.nl> (PvO) wrote:
> I found that the problem only occurs when the cursor is not inside the
> *Article* buffer. So it probably is related to this change:
>
>
> 2005-12-27 Richard M. Stallman <rms@gnu.org>
>
> * mouse.el (mouse-drag-region-1): When remapping mouse-1 to
> mouse-2, go back to previously selected window, so it's
> selected when mouse-2 command runs.
I updated from CVS last week for the first time in months, and one thing
I noticed happening was that sometimes, when the frame is split into two
windows, and I click with the mouse-1 button on a link in the
non-selected window (such as in a *Help* buffer, or on a URL highlighted
by goto-address in a text buffer), instead of following the link,
whatever random text happens to be in the clipboard (?) is pasted at
point in the selected window. It is as if, instead of clicking mouse-1
on a link in the non-selected window, I had clicked mouse-2 somewhere in
the selected window. Using mouse-2 follows the link correctly.
This only happens sometimes, and I have not come up with a recipe to
reproduce it reliably, so I didn't report it, but it looks possible that
the change Piet quoted above might be implicated.
Peter
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mouse-1 behaviour changed in gnus?
2006-01-07 12:06 ` public
@ 2006-01-11 15:31 ` Piet van Oostrum
0 siblings, 0 replies; 9+ messages in thread
From: Piet van Oostrum @ 2006-01-11 15:31 UTC (permalink / raw)
Please isn't there anybody that knows enough about mouse.el to find the
bug?
--
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: piet@vanoostrum.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mouse-1 behaviour changed in gnus?
2006-01-05 16:30 ` Piet van Oostrum
2006-01-07 12:06 ` public
@ 2006-02-16 21:19 ` Reiner Steib
2006-02-18 0:06 ` Richard M. Stallman
1 sibling, 1 reply; 9+ messages in thread
From: Reiner Steib @ 2006-02-16 21:19 UTC (permalink / raw)
Cc: emacs-devel
On Thu, Jan 05 2006, Piet van Oostrum wrote:
>>>>>> Piet van Oostrum <piet@cs.uu.nl> (PvO) wrote:
>
>>PvO> When I click mouse-1 on a link in a gnus *Article* buffer, the link
>>PvO> isn't followed, as in the previous version I had, but the buffer
>>PvO> scrolls one line. Mouse-2 does follow the link. Why is this?
>
> I found that the problem only occurs when the cursor is not inside the
> *Article* buffer. So it probably is related to this change:
>
> 2005-12-27 Richard M. Stallman <rms@gnu.org>
>
> * mouse.el (mouse-drag-region-1): When remapping mouse-1 to
> mouse-2, go back to previously selected window, so it's selected
> when mouse-2 command runs.
>
> I have looked into the code, but it isn't obvious to me what is wrong with
> it.
In case you didn't notice yet: Chong Yidong fixed it in CVS.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mouse-1 behaviour changed in gnus?
2006-02-16 21:19 ` Reiner Steib
@ 2006-02-18 0:06 ` Richard M. Stallman
2006-02-18 10:36 ` Reiner Steib
0 siblings, 1 reply; 9+ messages in thread
From: Richard M. Stallman @ 2006-02-18 0:06 UTC (permalink / raw)
Cc: piet, emacs-devel
In case you didn't notice yet: Chong Yidong fixed it in CVS.
SInce I do not use Gnus, and normally don't use the mouse anyway,
this is not something I could ever be likely to notice on my own.
Thanks for telling me.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mouse-1 behaviour changed in gnus?
2006-02-18 0:06 ` Richard M. Stallman
@ 2006-02-18 10:36 ` Reiner Steib
0 siblings, 0 replies; 9+ messages in thread
From: Reiner Steib @ 2006-02-18 10:36 UTC (permalink / raw)
On Sat, Feb 18 2006, Richard M. Stallman wrote:
> In case you didn't notice yet: Chong Yidong fixed it in CVS.
>
> SInce I do not use Gnus, and normally don't use the mouse anyway,
> this is not something I could ever be likely to notice on my own.
> Thanks for telling me.
I though this information could be new for Piet van Oostrum (who
originally reported this problem). Even better if my message also was
useful for you (I know that you don't use Gnus).
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-02-18 10:36 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-05 7:28 Mouse-1 behaviour changed in gnus? Piet van Oostrum
2006-01-05 14:30 ` Reiner Steib
2006-01-05 21:01 ` Piet van Oostrum
2006-01-05 16:30 ` Piet van Oostrum
2006-01-07 12:06 ` public
2006-01-11 15:31 ` Piet van Oostrum
2006-02-16 21:19 ` Reiner Steib
2006-02-18 0:06 ` Richard M. Stallman
2006-02-18 10:36 ` Reiner Steib
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).