bug#441: 23.0.60; Complicated combination of keymaps/remapping mistreated

bug#441: 23.0.60; Complicated combination of keymaps/remapping mistreated

[David Kastrup]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Hi, when reading news with an embedded URL, I am tempted to click on the
URL in the (non-selected!) article buffer with mouse-1.  This does not
work.  Asking about the keybinding delivers:

<down-mouse-1> (translated from <down-mouse-1> <down-mouse-1>) at that
spot runs the command widget-button-click, which is an interactive
compiled Lisp function in `wid-edit.el'.


(widget-button-click event)

Invoke the button that the mouse is pointing at.

----------------- up-event (short click) ----------------

<mouse-1> at that spot is remapped to <mouse-2>, which runs the
command mouse-yank-at-click, which is an interactive compiled Lisp
function in `mouse.el'.

It is bound to <right-fringe> <mouse-2>, <left-fringe> <mouse-2>.

(mouse-yank-at-click click arg)

Insert the last stretch of killed text at the position clicked on.
Also move point to one end of the text thus inserted (normally the end),
and set mark at the beginning.
Prefix arguments are interpreted as with C-y.
If `mouse-yank-at-point' is non-nil, insert at point
regardless of where you click.

----------------- up-event (long click) ----------------

Pressing <mouse-1> at that spot for longer than 450 milli-seconds
runs the command mouse-set-point, which is an interactive compiled
Lisp function in `mouse.el'.

It is bound to <mouse-1>, <double-mouse-1>, <triple-mouse-1>,
<right-fringe> <mouse-1>, <left-fringe> <mouse-1>.

(mouse-set-point event)

Move point to the position clicked on with the mouse.
This should be bound to a mouse click event type.

[back]

And the attempt to yank then fails (since this is a readonly buffer).

Ok, but if I am in the buffer itself, I just get

<down-mouse-1> at that spot runs the command widget-button-click,
which is an interactive compiled Lisp function in `wid-edit.el'.

It is bound to <down-mouse-2>, <down-mouse-1>.

(widget-button-click event)

Invoke the button that the mouse is pointing at.

[back]

Which works.


In GNU Emacs 23.0.60.4 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2008-06-17 on lisa
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
configured using `configure  '--prefix=/usr/local/emacs-21' '--without-toolkit-scroll-bars''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Summary

Minor modes in effect:
  shell-dirtrack-mode: t
  TeX-PDF-mode: t
  server-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:

Fetching headers for nntp+news.gmane.org:gmane.comp.gnu.utils.bugs...done
Generating summary...done
Mark set
insert-for-yank: Buffer is read-only: #<buffer *Article*>

-- 
David Kastrup

bug#441: 23.0.60; Complicated combination of keymaps/remapping mistreated

[Chong Yidong]

> Hi, when reading news with an embedded URL, I am tempted to click on
> the URL in the (non-selected!) article buffer with mouse-1.  This does
> not work.  Asking about the keybinding delivers:
>
> <down-mouse-1> (translated from <down-mouse-1> <down-mouse-1>) at that
> spot runs the command widget-button-click, which is an interactive
> compiled Lisp function in `wid-edit.el'.

I can't seem to reproduce this.  Left-clicking on any Gnus article
buffer (I assume you're referring to Gnus) opens the url as desired,
even if the article buffer isn't the selected window.

Do you still see this problem?  If so, could you check if it's something
in your customizations causing it?

bug#441: marked as done (23.0.60; Complicated combination of keymaps/remapping mistreated)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]


Your message dated Thu, 14 Aug 2008 10:09:22 -0400
with message-id <8763q3adt9.fsf@stupidchicken.com>
and subject line Re: 23.0.60; Complicated combination of keymaps/remapping mistreated
has caused the Emacs bug report #441,
regarding 23.0.60; Complicated combination of keymaps/remapping mistreated
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
441: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=441
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 5692 bytes --]

From: David Kastrup <dak@gnu.org>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; Complicated combination of keymaps/remapping mistreated
Date: Wed, 18 Jun 2008 11:30:19 +0200
Message-ID: <86lk13gkes.fsf@lola.quinscape.zz>


Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Hi, when reading news with an embedded URL, I am tempted to click on the
URL in the (non-selected!) article buffer with mouse-1.  This does not
work.  Asking about the keybinding delivers:

<down-mouse-1> (translated from <down-mouse-1> <down-mouse-1>) at that
spot runs the command widget-button-click, which is an interactive
compiled Lisp function in `wid-edit.el'.


(widget-button-click event)

Invoke the button that the mouse is pointing at.

----------------- up-event (short click) ----------------

<mouse-1> at that spot is remapped to <mouse-2>, which runs the
command mouse-yank-at-click, which is an interactive compiled Lisp
function in `mouse.el'.

It is bound to <right-fringe> <mouse-2>, <left-fringe> <mouse-2>.

(mouse-yank-at-click click arg)

Insert the last stretch of killed text at the position clicked on.
Also move point to one end of the text thus inserted (normally the end),
and set mark at the beginning.
Prefix arguments are interpreted as with C-y.
If `mouse-yank-at-point' is non-nil, insert at point
regardless of where you click.

----------------- up-event (long click) ----------------

Pressing <mouse-1> at that spot for longer than 450 milli-seconds
runs the command mouse-set-point, which is an interactive compiled
Lisp function in `mouse.el'.

It is bound to <mouse-1>, <double-mouse-1>, <triple-mouse-1>,
<right-fringe> <mouse-1>, <left-fringe> <mouse-1>.

(mouse-set-point event)

Move point to the position clicked on with the mouse.
This should be bound to a mouse click event type.

[back]

And the attempt to yank then fails (since this is a readonly buffer).

Ok, but if I am in the buffer itself, I just get

<down-mouse-1> at that spot runs the command widget-button-click,
which is an interactive compiled Lisp function in `wid-edit.el'.

It is bound to <down-mouse-2>, <down-mouse-1>.

(widget-button-click event)

Invoke the button that the mouse is pointing at.

[back]

Which works.


In GNU Emacs 23.0.60.4 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2008-06-17 on lisa
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
configured using `configure  '--prefix=/usr/local/emacs-21' '--without-toolkit-scroll-bars''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Summary

Minor modes in effect:
  shell-dirtrack-mode: t
  TeX-PDF-mode: t
  server-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:

Fetching headers for nntp+news.gmane.org:gmane.comp.gnu.utils.bugs...done
Generating summary...done
Mark set
insert-for-yank: Buffer is read-only: #<buffer *Article*>

-- 
David Kastrup



[-- Attachment #3: Type: message/rfc822, Size: 2144 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: 441-done@emacsbugs.donarmstrong.com
Subject: Re: 23.0.60; Complicated combination of keymaps/remapping mistreated
Date: Thu, 14 Aug 2008 10:09:22 -0400
Message-ID: <8763q3adt9.fsf@stupidchicken.com>

David Kastrup <dak@gnu.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>>> Hi, when reading news with an embedded URL, I am tempted to click on
>>> the URL in the (non-selected!) article buffer with mouse-1.  This does
>>> not work.  Asking about the keybinding delivers:
>>>
>>> <down-mouse-1> (translated from <down-mouse-1> <down-mouse-1>) at that
>>> spot runs the command widget-button-click, which is an interactive
>>> compiled Lisp function in `wid-edit.el'.
>>
>> I can't seem to reproduce this.  Left-clicking on any Gnus article
>> buffer (I assume you're referring to Gnus) opens the url as desired,
>> even if the article buffer isn't the selected window.
>>
>> Do you still see this problem?  If so, could you check if it's something
>> in your customizations causing it?
>
> It would appear like I can't currently reproduce this either.  If it
> crops up again, I'll holler.