mouse-1-click-follows-link and mime messages

mouse-1-click-follows-link and mime messages

[Chong Yidong]

With point in the Gnus article window, mouse-1 on links in the article
(e.g., mime attachments or URLs) performs the correct action (i.e.,
opening the attachment or following the URL).

However, with point is in the Gnus summary window, mouse-1 on the same
links does nothing.  Mouse-2 works fine.

Re: mouse-1-click-follows-link and mime messages

[Romain Francoise]

Chong Yidong <cyd@stupidchicken.com> writes:

> With point in the Gnus article window, mouse-1 on links in the article
> (e.g., mime attachments or URLs) performs the correct action (i.e.,
> opening the attachment or following the URL).

> However, with point is in the Gnus summary window, mouse-1 on the same
> links does nothing.  Mouse-2 works fine.

It's a bug in Emacs due 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.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: mouse-1-click-follows-link and mime messages

[Chong Yidong]

Romain Francoise <romain@orebokech.com> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> With point in the Gnus article window, mouse-1 on links in the article
>> (e.g., mime attachments or URLs) performs the correct action (i.e.,
>> opening the attachment or following the URL).
>
>> However, with point is in the Gnus summary window, mouse-1 on the same
>> links does nothing.  Mouse-2 works fine.
>
> It's a bug in Emacs due 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 don't recall what this change was for?  It seems like the wrong
change.  A function called from a mouse click can always call
`with-selected-window' if it needs to.

Re: mouse-1-click-follows-link and mime messages

[Romain Francoise]

> I don't recall what this change was for?

It fixes a bug reported by... Juri, I think.  I don't remember the
details.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: mouse-1-click-follows-link and mime messages

[Chong Yidong]

Romain Francoise <romain@orebokech.com> writes:

>> I don't recall what this change was for?
>
> It fixes a bug reported by... Juri, I think.  I don't remember the
> details.

Ah OK. I found it:

  In the *scratch* buffer type part of a symbol and type M-TAB.  In
  the *Completions* buffer click <mouse-1> on a completion string.

  First bug: point remains in the same window where the *Completions*
  buffer was before clicking <mouse-1> (the *Completions* buffer gets
  buried and replaced with another buffer).  But the correct behavior
  is switching the window back to the original window with the
  *scratch* buffer.

  So now switch manually to the window with the *scratch* buffer
  (`C-x o'), and call `undo' (`C-x u').  Second bug: it incorrectly
  puts point at the beginning of the initial string instead of the
  position where M-TAB was typed before inserting a completion string.

Maybe there is some other way to fix this...

Re: mouse-1-click-follows-link and mime messages

[Chong Yidong]

Romain Francoise <romain@orebokech.com> writes:

>> With point in the Gnus article window, mouse-1 on links in the article
>> (e.g., mime attachments or URLs) performs the correct action (i.e.,
>> opening the attachment or following the URL).
>
>> However, with point is in the Gnus summary window, mouse-1 on the same
>> links does nothing.  Mouse-2 works fine.
>
> It's a bug in Emacs due 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.

Looks like this affects all `link' widgets.  For instance, clicking on
the links in the Customize buffer does not work if another window is
selected.

(Removing ding@gnus.org from Cc:, since this is not a Gnus bug.)

Re: mouse-1-click-follows-link and mime messages

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Romain Francoise <romain@orebokech.com> writes:
>
>>> With point in the Gnus article window, mouse-1 on links in the article
>>> (e.g., mime attachments or URLs) performs the correct action (i.e.,
>>> opening the attachment or following the URL).
>>
>>> However, with point is in the Gnus summary window, mouse-1 on the same
>>> links does nothing.  Mouse-2 works fine.
>>
>> It's a bug in Emacs due 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.
>
> Looks like this affects all `link' widgets.  For instance, clicking on
> the links in the Customize buffer does not work if another window is
> selected.

I debugged this some more.  One way to fix it (without reverting RMS's
change) is to change the :follow-link property of the `link' widget:

*** /home/cyd/emacs/lisp/wid-edit.el.~1.163.~	2006-02-07 18:22:31.000000000 -0500
--- /home/cyd/emacs/lisp/wid-edit.el	2006-02-07 19:32:34.000000000 -0500
***************
*** 1754,1760 ****
    "An embedded link."
    :button-prefix 'widget-link-prefix
    :button-suffix 'widget-link-suffix
!   :follow-link "\C-m"
    :help-echo "Follow the link."
    :format "%[%t%]")
  
--- 1754,1760 ----
    "An embedded link."
    :button-prefix 'widget-link-prefix
    :button-suffix 'widget-link-suffix
!   :follow-link 'widget-button-click
    :help-echo "Follow the link."
    :format "%[%t%]")
  
However, another strange bug surfaces if you do this.  Do
M-x customize in one window, and select another window.  Click mouse-1
on "Custom file" in the Customize buffer.  With the above patch, this
works: the Info file is opened in that window, as expected.  Now,
hover the mouse over one of the links in the header line.  An error is
signalled:

  Debugger entered--Lisp error: (args-out-of-range 1875 1875)
  get-char-property(1875 follow-link)
  mouse-on-link-p((#<window 6 on *info*> header-line (118 . 13) 0
    (#("Next: Face Customization,  Prev: Changing a Variable,  Up: Easy
        Customization" 0 6 ... 6 24 ... 24 27 nil 27 33 ... 33 52 ... 52 55
        nil 55 59 ... 59 77 ...) . 16) 1875 (16 . -1) nil (6 . 13) (7 . 14)))
  mouse-fixup-help-message(#("mouse-2: Go to node Face Customization"
    0 20 nil 20 38 (font-lock-face info-header-xref mouse-face highlight)))
  read-event()
  byte-code("...")
  (track-mouse (byte-code "..."))
  (lambda nil (track-mouse (byte-code "...")
  mouse-drag-track((down-mouse-1 (#<window 6 on *info*> 315 (60 . 82)
    200741335 nil 315 (8 . 5) nil (4 . 12) (7 . 14))) t)
  mouse-drag-region((down-mouse-1 (#<window 6 on *info*> 315 (60 . 82)
    200741335 nil 315 (8 . 5) nil (4 . 12) (7 . 14))))
  call-interactively(mouse-drag-region)

Any ideas?

Re: mouse-1-click-follows-link and mime messages

[Richard M. Stallman]

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

    Looks like this affects all `link' widgets.  For instance, clicking on
    the links in the Customize buffer does not work if another window is
    selected.

The change I made is correct in principle.  When the mouse-2 command
finally gets run, the selected window should not have been altered by
the translation mechanism.  The event says which window was clicked
on.  The selected window should be the one that was selected by the
user.

It sounds like the command that handles mouse-2 on a link needs fixing.

Re: mouse-1-click-follows-link and mime messages

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

>     > 	* 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.
>
>     Looks like this affects all `link' widgets.  For instance, clicking on
>     the links in the Customize buffer does not work if another window is
>     selected.
>
> The change I made is correct in principle.  When the mouse-2 command
> finally gets run, the selected window should not have been altered by
> the translation mechanism.  The event says which window was clicked
> on.  The selected window should be the one that was selected by the
> user.
>
> It sounds like the command that handles mouse-2 on a link needs fixing.

I figured out the problem.  We should only change the selected window
if we are translating to mouse-2.  The `follow-link' property can also
specify translation to, e.g., "\C-m" (in the case of the link widget);
in that case, we shouldn't change the window.

I've checked in a fix.

Re: mouse-1-click-follows-link and mime messages

[Richard M. Stallman]

    --- /home/cyd/emacs/lisp/wid-edit.el	2006-02-07 19:32:34.000000000 -0500
    ***************
    *** 1754,1760 ****
	"An embedded link."
	:button-prefix 'widget-link-prefix
	:button-suffix 'widget-link-suffix
    !   :follow-link "\C-m"
	:help-echo "Follow the link."
	:format "%[%t%]")

    --- 1754,1760 ----
	"An embedded link."
	:button-prefix 'widget-link-prefix
	:button-suffix 'widget-link-suffix
    !   :follow-link 'widget-button-click
	:help-echo "Follow the link."
	:format "%[%t%]")

If that fixes the problem, I suspect there may be a bug in
the code that implements :follow-link.  Maybe that code
needs to select the window that the link is in.
Could you take a look?

    Now,
    hover the mouse over one of the links in the header line.  An error is
    signalled:

      Debugger entered--Lisp error: (args-out-of-range 1875 1875)
      get-char-property(1875 follow-link)
      mouse-on-link-p((#<window 6 on *info*> header-line (118 . 13) 0
	(#("Next: Face Customization,  Prev: Changing a Variable,  Up: Easy
	    Customization" 0 6 ... 6 24 ... 24 27 nil 27 33 ... 33 52 ... 52 55
	    nil 55 59 ... 59 77 ...) . 16) 1875 (16 . -1) nil (6 . 13) (7 . 14)))

I suspect that is a simple bug in mouse-on-link-p, that it doesn't
handle all the possible formats of an event.

Re: mouse-1-click-follows-link and mime messages

[Richard M. Stallman]

    I figured out the problem.  We should only change the selected window
    if we are translating to mouse-2.  The `follow-link' property can also
    specify translation to, e.g., "\C-m" (in the case of the link widget);
    in that case, we shouldn't change the window.

    I've checked in a fix.

Thanks.

Re: mouse-1-click-follows-link and mime messages

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     I figured out the problem.  We should only change the selected window
>     if we are translating to mouse-2.  The `follow-link' property can also
>     specify translation to, e.g., "\C-m" (in the case of the link widget);
>     in that case, we shouldn't change the window.
>
>     I've checked in a fix.
>
> Thanks.

While I think the fix reasonable, I'd suggest that follow-link should,
when feasible, try to map through a mouse event.  Link-like fields
sometimes have an interactive spec not containing "@" which means that
they will not switch the selected window while doing their action
through a mouse click.  A translation to a mouse event can keep those
semantics; a translation to a keyboard event does not seem to make
sense without changing the selected window.

So as a rule of thumb, follow-link should probably not revert to a
keyboard event when this can be avoided in favor of an interactive
form or event intended for the mouse.  In particular when mouse-2 does
not do "@" in its interactive spec.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

mouse-1 drag invokes follow-link (was: mouse-1-click-follows-link and mime messages)

[Reiner Steib]

On Wed, Feb 08 2006, Chong Yidong wrote:

> "Richard M. Stallman" <rms@gnu.org> writes:
[...]
>> The change I made is correct in principle.  When the mouse-2 command
>> finally gets run, the selected window should not have been altered by
>> the translation mechanism.  The event says which window was clicked
>> on.  The selected window should be the one that was selected by the
>> user.
>>
>> It sounds like the command that handles mouse-2 on a link needs fixing.
>
> I figured out the problem.  We should only change the selected window
> if we are translating to mouse-2.  The `follow-link' property can also
> specify translation to, e.g., "\C-m" (in the case of the link widget);
> in that case, we shouldn't change the window.
>
> I've checked in a fix.

Thanks for fixing this.  But I think these changes have introduced a
different problem:

In Gnus, when in the article buffer, I try to select the text
"stupidchicken" in your "From" header by dragging with mouse-1 from
"s" to "n", it follows the link (e.g. composing a mail to the author)
instead of selecting the text.

I have reproduced this problem using the Emacs-bundled Gnus 5.11 and a
minimal Gnus setup.  A 2006-01-27 build behaves as expected.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: mouse-1 drag invokes follow-link

[Chong Yidong]

Reiner Steib <reinersteib+from-uce@imap.cc> writes:

> Thanks for fixing this.  But I think these changes have introduced a
> different problem:
>
> In Gnus, when in the article buffer, I try to select the text
> "stupidchicken" in your "From" header by dragging with mouse-1 from
> "s" to "n", it follows the link (e.g. composing a mail to the author)
> instead of selecting the text.
>
> I have reproduced this problem using the Emacs-bundled Gnus 5.11 and a
> minimal Gnus setup.  A 2006-01-27 build behaves as expected.

Thanks, I believe this should be fixed now.  (The code in wid-edit.el
is a little magical, so please test it out and make sure it really
works.)

Re: mouse-1 drag invokes follow-link

[Reiner Steib]

On Thu, Feb 16 2006, Chong Yidong wrote:

> Reiner Steib <reinersteib+from-uce@imap.cc> writes:
>> In Gnus, when in the article buffer, I try to select the text
>> "stupidchicken" in your "From" header by dragging with mouse-1 from
>> "s" to "n", it follows the link (e.g. composing a mail to the author)
>> instead of selecting the text.
[...]
> Thanks, I believe this should be fixed now.  

Thanks.

> (The code in wid-edit.el is a little magical, so please test it out
> and make sure it really works.)

I've been using the new built for several hours now.  It works
correctly, AFAICS.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/