GNU bug report logs -
#59351
29.0.50; [PATCH] Fix mouse click position to menu bar entry
Previous Next
Reported by: Manuel Giraud <manuel <at> ledu-giraud.fr>
Date: Fri, 18 Nov 2022 08:38:02 UTC
Severity: normal
Tags: patch
Found in version 29.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: luangruo <at> yahoo.com, 59351 <at> debbugs.gnu.org
> Date: Fri, 18 Nov 2022 14:20:15 +0100
>
> > Did you test the results on a TTY frame that has a mouse?
>
> It doesn't even compile --without-x. So here is a new version of this
> patch. I even remove the comment as suggested by Po.
>
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -5974,8 +5974,17 @@ make_lispy_event (struct input_event *event)
> in a menu (non-toolkit version). */
> if (!toolkit_menubar_in_use (f))
> {
> +#if defined HAVE_WINDOW_SYSTEM
> + int dummy;
> +
> + x_y_to_hpos_vpos (XWINDOW (f->menu_bar_window),
> + XFIXNUM (event->x), XFIXNUM (event->y),
> + &column, &row,
> + NULL, NULL, &dummy);
> +#else
> pixel_to_glyph_coords (f, XFIXNUM (event->x), XFIXNUM (event->y),
> &column, &row, NULL, 1);
> +#endif
This cannot be a compile-time condition, because Emacs compiled with X
support can still have TTY frames. So you need to test for
FRAME_WINDOW_P, and only call x_y_to_hpos_vpos if FRAME_WINDOW_P
returns non-zero; otherwise call pixel_to_glyph_coords even in a build
where HAVE_WINDOW_SYSTEM is defined.
This bug report was last modified 2 years and 250 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.