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