GNU bug report logs - #64750
30.0.50; [PATCH] Clicking at screen edge in X11 echoes "<nil> <mouse-1> is undefined"

Previous Next

Package: emacs;

Reported by: Antero Mejr <antero <at> mailbox.org>

Date: Thu, 20 Jul 2023 18:13:01 UTC

Severity: normal

Tags: notabug, patch

Found in version 30.0.50

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#64750; Package emacs. (Thu, 20 Jul 2023 18:13:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Antero Mejr <antero <at> mailbox.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 20 Jul 2023 18:13:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Antero Mejr <antero <at> mailbox.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; [PATCH] Clicking at screen edge in X11 echoes "<nil>
 <mouse-1> is undefined"
Date: Thu, 20 Jul 2023 18:12:31 +0000
[Message part 1 (text/plain, inline)]
When clicking along the left edge of screen in a maximized emacs X11
window, the message "<left-fringe> <mouse-1> is undefined" or
"<nil> <mouse-1> is undefined" will appear. This can also be done with
the right fringe, and with the top edge of the screen if the menu and
tool bars are disabled. It can also be done using mouse events besides
<mouse-1>, like <mouse-2>, <down-mouse-1>, or <drag-mouse-1>.

This occurs with emacs -Q, regardless of fringe mode or internal border
settings. It is easier to reproduce with larger internal borders (-ib 10
or so) or larger fringes, because that expands the size of the nil or
fringe area. When internal border and fringes are disabled, there is
still a 1-pixel wide area with this problem.

This bug makes using programs with clickable UI elements at the edge of
the frame annoying. The cursor tends to land in the nil or fringe areas,
then the distracting/irrelevant message appears in the echo area when
you attempt to click.

The attached patch globally ignores all inputs for those areas in
fringe.el.

[0001-Ignore-input-in-the-fringe-and-nil-areas.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#64750; Package emacs. (Thu, 20 Jul 2023 18:37:01 GMT) Full text and rfc822 format available.

Message #8 received at 64750 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Antero Mejr <antero <at> mailbox.org>
Cc: 64750 <at> debbugs.gnu.org
Subject: Re: bug#64750: 30.0.50;
 [PATCH] Clicking at screen edge in X11 echoes "<nil> <mouse-1> is
 undefined"
Date: Thu, 20 Jul 2023 21:36:40 +0300
tags 64750 notabug
thanks

> Date: Thu, 20 Jul 2023 18:12:31 +0000
> From:  Antero Mejr via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> When clicking along the left edge of screen in a maximized emacs X11
> window, the message "<left-fringe> <mouse-1> is undefined" or
> "<nil> <mouse-1> is undefined" will appear. This can also be done with
> the right fringe, and with the top edge of the screen if the menu and
> tool bars are disabled. It can also be done using mouse events besides
> <mouse-1>, like <mouse-2>, <down-mouse-1>, or <drag-mouse-1>.

This is the correct and intended behavior, not a bug.  When the user
invokes a key sequence or a mouse gesture that is not bound to any
command, Emacs says so.

> This bug makes using programs with clickable UI elements at the edge of
> the frame annoying. The cursor tends to land in the nil or fringe areas,
> then the distracting/irrelevant message appears in the echo area when
> you attempt to click.
> 
> The attached patch globally ignores all inputs for those areas in
> fringe.el.

Thanks, but I don't think we should install this.  If the behavior you
described annoys you that much, you can always add these bindings to
your personal init files -- that's why Emacs makes it easy to
customize key bindings.  But in general, arbitrarily ignoring key
sequences just because they are not bound to commands is not TRT, IMO.




Added tag(s) notabug. Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Thu, 20 Jul 2023 18:37:02 GMT) Full text and rfc822 format available.

Reply sent to Stefan Kangas <stefankangas <at> gmail.com>:
You have taken responsibility. (Sun, 03 Sep 2023 10:35:02 GMT) Full text and rfc822 format available.

Notification sent to Antero Mejr <antero <at> mailbox.org>:
bug acknowledged by developer. (Sun, 03 Sep 2023 10:35:02 GMT) Full text and rfc822 format available.

Message #15 received at 64750-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Antero Mejr <antero <at> mailbox.org>, 64750-done <at> debbugs.gnu.org
Subject: Re: bug#64750: 30.0.50; [PATCH] Clicking at screen edge in X11 echoes
 "<nil> <mouse-1> is undefined"
Date: Sun, 3 Sep 2023 03:34:18 -0700
Eli Zaretskii <eliz <at> gnu.org> writes:

> tags 64750 notabug
> thanks
>
>> Date: Thu, 20 Jul 2023 18:12:31 +0000
>> From:  Antero Mejr via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> When clicking along the left edge of screen in a maximized emacs X11
>> window, the message "<left-fringe> <mouse-1> is undefined" or
>> "<nil> <mouse-1> is undefined" will appear. This can also be done with
>> the right fringe, and with the top edge of the screen if the menu and
>> tool bars are disabled. It can also be done using mouse events besides
>> <mouse-1>, like <mouse-2>, <down-mouse-1>, or <drag-mouse-1>.
>
> This is the correct and intended behavior, not a bug.  When the user
> invokes a key sequence or a mouse gesture that is not bound to any
> command, Emacs says so.
>
>> This bug makes using programs with clickable UI elements at the edge of
>> the frame annoying. The cursor tends to land in the nil or fringe areas,
>> then the distracting/irrelevant message appears in the echo area when
>> you attempt to click.
>>
>> The attached patch globally ignores all inputs for those areas in
>> fringe.el.
>
> Thanks, but I don't think we should install this.  If the behavior you
> described annoys you that much, you can always add these bindings to
> your personal init files -- that's why Emacs makes it easy to
> customize key bindings.  But in general, arbitrarily ignoring key
> sequences just because they are not bound to commands is not TRT, IMO.

I'm therefore closing this bug report.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 01 Oct 2023 11:24:21 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 223 days ago.

Previous Next


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