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

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

[Drew Adams]

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

> Can you please provide a complete recipe, starting from "emacs -Q",
> for creating such a frame?  That should make reproducing the problem
> much easier.

It took me a while to narrow it down. But I think this is minimal -
seems like everything here is needed.  See attached file, onetest4.el.

1. Start Emacs with an MS Windows shortcut that has this target:
runemacs.exe -Q --debug-init -l "onetest4.el" -f "1on1-emacs" "onetest4.el"

2. Click the title bar of the minibuffer frame (not needed, but
   just to make sure the frame is selected.

3. C-h k

4. Click mouse-1 somewhere in the second line of the minibuffer frame.

You see this message:
<nil> <down-mouse-1> (translated from <down-mouse-1>) at that spot is undefined

Click again.  You see this message:
<nil> <mouse-1> is undefined

Check buffer *Messages*, and you see something like this:

For information about GNU Emacs and the GNU system, type C-h C-a.
<nil> <down-mouse-1> (translated from <down-mouse-1>) at that spot is undefined
<nil> <down-mouse-1> is undefined
<nil> <mouse-1> is undefined

[-- Attachment #2: onetest4.el --]
[-- Type: application/octet-stream, Size: 441 bytes --]

;; runemacs.exe -Q --debug-init  -l "onetest4.el" -f "1on1-emacs" "onetest4.el"


(defun 1on1-emacs ()
  ""
  (interactive)
  (setq default-frame-alist
        (list
         '(font . "-*-Lucida Console-normal-r-*-*-14-*-*-*-c-*-iso8859-1")
         '(bottom-divider-width . 2)
         '(minibuffer)))
  (setq pop-up-frames  t)
  (setq minibuffer-frame-alist (list '(height . 2)
                                     '(minibuffer . only))))

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

[Eli Zaretskii]

> Date: Thu, 8 Oct 2015 11:39:44 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 21643@debbugs.gnu.org
> 
> 1. Start Emacs with an MS Windows shortcut that has this target:
> runemacs.exe -Q --debug-init -l "onetest4.el" -f "1on1-emacs" "onetest4.el"
> 
> 2. Click the title bar of the minibuffer frame (not needed, but
>    just to make sure the frame is selected.
> 
> 3. C-h k
> 
> 4. Click mouse-1 somewhere in the second line of the minibuffer frame.
> 
> You see this message:
> <nil> <down-mouse-1> (translated from <down-mouse-1>) at that spot is undefined

Thanks.  There's clearly some display bug that shows in the minibuffer
frame: look carefully and you will see that the fringes and the scroll
bar only extend for a single line there.  The second line is some kind
of "no-man's land", which explains the "nil" part in the mouse event.

If you drag the lower edge of the minibuffer frame by even a single
pixel, then return it back to its original (or even smaller) height,
the problem with the fringes goes away, and so does the problem with
the mouse click.

I will take a look.

Martin, this looks somewhat similar to the problem you solved the
other day, whereby "M-x" echo would not be visible.  So maybe you
could look into this as well, if you have time.

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

[martin rudalics]

 > Martin, this looks somewhat similar to the problem you solved the
 > other day, whereby "M-x" echo would not be visible.  So maybe you
 > could look into this as well, if you have time.

Should be fixed now.  The bug could be triggered only by giving the
minibuffer height twice the height it had before.  It goes without
saying that Drew succeeded.

Thanks for making it easily reproducible, martin

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

[Eli Zaretskii]

> Date: Fri, 09 Oct 2015 12:06:59 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 21643@debbugs.gnu.org
> 
>  > Martin, this looks somewhat similar to the problem you solved the
>  > other day, whereby "M-x" echo would not be visible.  So maybe you
>  > could look into this as well, if you have time.
> 
> Should be fixed now.  The bug could be triggered only by giving the
> minibuffer height twice the height it had before.  It goes without
> saying that Drew succeeded.

Thanks.

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

[Drew Adams]

> Thanks.  There's clearly some display bug that shows in the
> minibuffer
> frame: look carefully and you will see that the fringes and the
> scroll
> bar only extend for a single line there.  The second line is some
> kind
> of "no-man's land", which explains the "nil" part in the mouse
> event.
> 
> If you drag the lower edge of the minibuffer frame by even a single
> pixel, then return it back to its original (or even smaller) height,
> the problem with the fringes goes away, and so does the problem with
> the mouse click.

Yes, I figured nearly as much, even in my setup (where I don't show fringe).

FWIW, in Emacs 19 there was such a no-man's land underneath each scroll
bar (everywhere, not minibuffer frame).  And I used that "feature" by
binding keys there.  I was disappointed when this "feature" was removed. ;-)

This is the code I used for that:

;;;   ;; These [nil] bindings are no doubt a HACK, based on an
;;;   ;; undocumented handy "feature".  (This works in Emacs 19.34.6,
;;;   ;; but it doesn't work in Emacs 20.6.)  In Windows, at least,
;;;   ;; such a key sequence [nil...] occurs if you click in the
;;;   ;; lower right corner, between the scroll bar and the mode-line.
;;;   ;;
;;;   (global-set-key [nil down-mouse-1] 'fit-frame)
;;;   (global-set-key [nil mouse-1] 'ignore)
;;;   (global-set-key [nil C-down-mouse-1] 'show-hide)
;;;   (global-set-key [nil C-mouse-1] 'ignore)
;;;   (global-set-key [nil S-down-mouse-1] 'iconify-everything)
;;;   (global-set-key [nil S-mouse-1] 'ignore)

I had a hunch that this <nil> was akin to the nil in that feature.

> I will take a look.

Thank you.

> Martin, this looks somewhat similar to the problem you solved the
> other day, whereby "M-x" echo would not be visible.  So maybe you
> could look into this as well, if you have time.

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

[Drew Adams]

> FWIW, in Emacs 19 there was such a no-man's land underneath each
> scroll bar (everywhere, not minibuffer frame).  And I used that
> "feature" by binding keys there.  I was disappointed when this
> "feature" was removed. ;-)
 
FWIW, here is a 2004 reference to this "feature", in a discussion
about handles for dragging window dividers:

http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg00125.html

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

[Drew Adams]

> Thanks.

That was quick.  Thx.

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

[Drew Adams]

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

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

[Eli Zaretskii]

> Date: Wed, 7 Oct 2015 15:15:54 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> 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).

Can you please provide a complete recipe, starting from "emacs -Q",
for creating such a frame?  That should make reproducing the problem
much easier.

Thanks.

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

[Stefan Kangas]

close 21643 25.1
thanks

martin rudalics <rudalics@gmx.at> writes:

>> Martin, this looks somewhat similar to the problem you solved the
>> other day, whereby "M-x" echo would not be visible.  So maybe you
>> could look into this as well, if you have time.
>
> Should be fixed now.  The bug could be triggered only by giving the
> minibuffer height twice the height it had before.  It goes without
> saying that Drew succeeded.
>
> Thanks for making it easily reproducible, martin

This was fixed at the time:

commit e6013e8c8f3de0ca39c17a2da95346b4a320e6d0
Author: Martin Rudalics <rudalics@gmx.at>
Date:   Fri Oct 9 11:55:06 2015 +0200

    In adjust_frame_size don't count minibuffer height twice (Bug#21643)

    * src/frame.c (adjust_frame_size): In minibuffer-only windows
    don't count minibuffer height twice.  (Bug#21643)

I'm therefore closing this bug report.

Best regards,
Stefan Kangas