GNU bug report logs - #441
23.0.60; Complicated combination of keymaps/remapping mistreated

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 441 in the body.
You can then email your comments to 441 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; Complicated combination of keymaps/remapping mistreated
Date: Wed, 18 Jun 2008 11:30:19 +0200

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

Message #10 received at 441 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: David Kastrup <dak <at> gnu.org>
Cc: 441 <at> debbugs.gnu.org
Subject: Re: 23.0.60; Complicated combination of keymaps/remapping mistreated
Date: Tue, 12 Aug 2008 17:42:55 -0400

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

Message #15 received at 441-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: 441-done <at> debbugs.gnu.org
Subject: Re: 23.0.60; Complicated combination of keymaps/remapping mistreated
Date: Thu, 14 Aug 2008 10:09:22 -0400

David Kastrup <dak <at> gnu.org> writes:

> Chong Yidong <cyd <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.