bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21643: 25.0.50; Error "<nil> <down-mouse-1> is undefined"


From: Drew Adams
Subject: bug#21643: 25.0.50; Error "<nil> <down-mouse-1> is undefined"
Date: Wed, 7 Oct 2015 15:15:54 -0700 (PDT)

I see the new behavior described below ever since this build:
GNU Emacs 24.4.50.1 (i686-pc-mingw32) of 2014-08-15 on LEG570

I do not see it in this build or older:
GNU Emacs 24.4.50.1 (i686-pc-mingw32) of 2014-06-28 on ODIEONE

The behavior:

In a standalone minibuffer frame that is two lines tall, in an inactive
minibuffer, I click mouse-1 near the bottom of the frame (so, somewhere
in the second of the two frame lines).

In the old builds, I get the keys <down-mouse-1> and <mouse-1> described
in *Help*, as usual:

  <down-mouse-1> at that spot runs the command mouse-drag-region, which
  is an interactive compiled Lisp function in `mouse.el'.

  It is bound to down-mouse-1.
  ...
  <mouse-1> at that spot runs the command mouse-set-point, which is an
  interactive compiled Lisp function in `mouse.el'.

  It is bound to mouse-1.
  ...

In the newer builds I get only these messages in *Messages*, each
preceded by a ding:

  <nil> <down-mouse-1> is undefined
  <nil> <mouse-1> is undefined

I'm guessing that that position in the frame is somehow considered to
be on a different GUI element, and this results in Emacs sending a
pseudo function key <nil>.

1. Could someone please explain what I'm seeing?  What is <nil>?
   What GUI element does Emacs think I am clicking on?

2. How can I bind these keys, whatever and wherever they are, to the
   usual commands, so that I can get the behavior I want?

This matters to me because I redefine `mouse-drag-region' so that a
`mouse-1' click in the inactive minibuffer when *Messages* is already
shown has the effect of `M-x'.  IOW, if *Messages* is not shown then
`mouse-1' shows it, and if it is already shown then `M-x' is invoked.

With whatever was changed in Emacs, this now works only if you click
`mouse-1' somewhere on the first line of the minibuffer frame (even if
after eob).  If you click on the second line then I get the odd behavior
described above.

The minibuffer frame has these frame parameters:
((tool-bar-position . top)
 (parent-id)
 (explicit-name . t)
 (display . "w32")
 (visibility . t)
 (icon-name)
 (window-id . "724602")
 (top . 990)
 (left . 0)
 (buried-buffer-list)
 (buffer-list #<buffer  *Minibuf-0*> #<buffer  *Minibuf-1*> #<buffer *scratch*>)
 (unsplittable . t)
 (minibuffer . only)
 (modeline)
 (width . 240)
 (height . 2)
 (name . "Emacs minibuffer                         show/hide: hold CTRL + click 
in window")
 (cursor-color . "Black")
 (background-mode . light)
 (display-type . color)
 (desktop-dont-save . t)
 (fringe . 0)
 (scroll-bar-height . 0)
 (scroll-bar-width . 0)
 (cursor-type . bar)
 (auto-lower)
 (auto-raise)
 (icon-type)
 (fullscreen)
 (title)
 (buffer-predicate)
 (tool-bar-lines . 0)
 (menu-bar-lines . 0)
 (alpha)
 (right-fringe . 0)
 (left-fringe . 0)
 (line-spacing)
 (screen-gamma)
 (border-color . "black")
 (mouse-color . "Black")
 (background-color . "LightBlue")
 (foreground-color . "Red")
 (horizontal-scroll-bars)
 (vertical-scroll-bars)
 (bottom-divider-width . 2)
 (right-divider-width . 2)
 (internal-border-width . 0)
 (border-width . 2)
 (font . "-outline-Lucida 
Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1")
 (font-parameter . "-*-Lucida Console-normal-r-*-*-14-*-*-*-c-*-iso8859-1")
 (font-backend uniscribe gdi))



In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2015-10-06
Bzr revision: a4a98a1b2568793ead43e824ecf227768759df12
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''





reply via email to

[Prev in Thread] Current Thread [Next in Thread]