unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#71761: 29.3; Emacs-Lisp menu display is incorrect during Edebug
@ 2024-06-24 20:32 tpeplt
  2024-06-28 18:10 ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: tpeplt @ 2024-06-24 20:32 UTC (permalink / raw)
  To: 71761

Emacs Maintainers,

   When a function has been instrumented for debugging with
Edebug and the debugger has entered the function for
stepping, the menu item ‘Emacs-Lisp’ does not list the
correct entries (which should be the same entries as they
were before entering the debugger) in its drop-down menu.
Instead, the drop-down menu lists two entries ‘Emacs-Lisp’
and ‘Emacs-Lisp’.  These two entries, in turn, are sub-menus
whose contents are the correct menu items for ‘Emacs-Lisp’,
namely, ‘Indent Line’, ‘Indent Region’, and so on.

   After exiting the debugger, the menu items for the
‘Emacs-Lisp’ menu item are displayed correctly.

Recipe for reproducing this menu-display error:

   1. Start Emacs from a shell prompt with: $ emacs -Q

   2. Create a new Emacs Lisp file with C-x C-f, say,
      new-file.el

   3. Create a simple Emacs Lisp function:

      (defun new-fun (name)
        (if name 'some-name nil))

   4. Instrument the function with C-u M-C-x.

   5. Check the menu listing for ‘Emacs-Lisp’ to confirm
      that it is correct.

   6. Invoke the instrumented function to enter Edebug:

      (new-fun t)

   7. Check the menu listing for ‘Emacs-Lisp’ to see that it
      now lists (only) two identical ‘Emacs-Lisp’ entries,
      each of which is a sub-menu.  The sub-menus will list
      the correct entries for ‘Emacs-Lisp’.

   8. In the debugger, type ‘c’ to continue to complete the
      debugging session.  Once it has exited, check the
      ‘Emacs-Lisp’ menu item to confirm that it now has the
      correct entries.  Each time that Edebug is entered,
      the ‘Emacs-Lisp’ menu’s entries are two incorrect
      sub-menus.

   Please let me know if anything above is unclear or if you are unable
to reproduce this problem.

-- 





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#71761: 29.3; Emacs-Lisp menu display is incorrect during Edebug
  2024-06-24 20:32 bug#71761: 29.3; Emacs-Lisp menu display is incorrect during Edebug tpeplt
@ 2024-06-28 18:10 ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-29 11:05   ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-28 18:10 UTC (permalink / raw)
  To: tpeplt; +Cc: 71761

tpeplt <tpeplt@gmail.com> writes:

> Emacs Maintainers,
>
>    When a function has been instrumented for debugging with
> Edebug and the debugger has entered the function for
> stepping, the menu item ‘Emacs-Lisp’ does not list the
> correct entries (which should be the same entries as they
> were before entering the debugger) in its drop-down menu.
> Instead, the drop-down menu lists two entries ‘Emacs-Lisp’
> and ‘Emacs-Lisp’.  These two entries, in turn, are sub-menus
> whose contents are the correct menu items for ‘Emacs-Lisp’,
> namely, ‘Indent Line’, ‘Indent Region’, and so on.
>
>    After exiting the debugger, the menu items for the
> ‘Emacs-Lisp’ menu item are displayed correctly.
>
> Recipe for reproducing this menu-display error:
>
>    1. Start Emacs from a shell prompt with: $ emacs -Q
>
>    2. Create a new Emacs Lisp file with C-x C-f, say,
>       new-file.el
>
>    3. Create a simple Emacs Lisp function:
>
>       (defun new-fun (name)
>         (if name 'some-name nil))
>
>    4. Instrument the function with C-u M-C-x.
>
>    5. Check the menu listing for ‘Emacs-Lisp’ to confirm
>       that it is correct.
>
>    6. Invoke the instrumented function to enter Edebug:
>
>       (new-fun t)
>
>    7. Check the menu listing for ‘Emacs-Lisp’ to see that it
>       now lists (only) two identical ‘Emacs-Lisp’ entries,
>       each of which is a sub-menu.  The sub-menus will list
>       the correct entries for ‘Emacs-Lisp’.
>
>    8. In the debugger, type ‘c’ to continue to complete the
>       debugging session.  Once it has exited, check the
>       ‘Emacs-Lisp’ menu item to confirm that it now has the
>       correct entries.  Each time that Edebug is entered,
>       the ‘Emacs-Lisp’ menu’s entries are two incorrect
>       sub-menus.
>
>    Please let me know if anything above is unclear or if you are unable
> to reproduce this problem.

The following may help to narrow down the problem:

In Emacs 29.4:
I am able to reproduce the bug in Emacs GUI
But in Emacs TTY (emacs -nw), the problem seems absent, the menu bar
appears correct.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#71761: 29.3; Emacs-Lisp menu display is incorrect during Edebug
  2024-06-28 18:10 ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-29 11:05   ` Eli Zaretskii
  2024-06-29 12:20     ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-30  4:12     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2024-06-29 11:05 UTC (permalink / raw)
  To: Jeremy Bryant, Stefan Monnier; +Cc: 71761, tpeplt

> Cc: 71761@debbugs.gnu.org
> Date: Fri, 28 Jun 2024 19:10:05 +0100
> From:  Jeremy Bryant via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> tpeplt <tpeplt@gmail.com> writes:
> 
> > Emacs Maintainers,
> >
> >    When a function has been instrumented for debugging with
> > Edebug and the debugger has entered the function for
> > stepping, the menu item ‘Emacs-Lisp’ does not list the
> > correct entries (which should be the same entries as they
> > were before entering the debugger) in its drop-down menu.
> > Instead, the drop-down menu lists two entries ‘Emacs-Lisp’
> > and ‘Emacs-Lisp’.  These two entries, in turn, are sub-menus
> > whose contents are the correct menu items for ‘Emacs-Lisp’,
> > namely, ‘Indent Line’, ‘Indent Region’, and so on.
> >
> >    After exiting the debugger, the menu items for the
> > ‘Emacs-Lisp’ menu item are displayed correctly.
> >
> > Recipe for reproducing this menu-display error:
> >
> >    1. Start Emacs from a shell prompt with: $ emacs -Q
> >
> >    2. Create a new Emacs Lisp file with C-x C-f, say,
> >       new-file.el
> >
> >    3. Create a simple Emacs Lisp function:
> >
> >       (defun new-fun (name)
> >         (if name 'some-name nil))
> >
> >    4. Instrument the function with C-u M-C-x.
> >
> >    5. Check the menu listing for ‘Emacs-Lisp’ to confirm
> >       that it is correct.
> >
> >    6. Invoke the instrumented function to enter Edebug:
> >
> >       (new-fun t)
> >
> >    7. Check the menu listing for ‘Emacs-Lisp’ to see that it
> >       now lists (only) two identical ‘Emacs-Lisp’ entries,
> >       each of which is a sub-menu.  The sub-menus will list
> >       the correct entries for ‘Emacs-Lisp’.
> >
> >    8. In the debugger, type ‘c’ to continue to complete the
> >       debugging session.  Once it has exited, check the
> >       ‘Emacs-Lisp’ menu item to confirm that it now has the
> >       correct entries.  Each time that Edebug is entered,
> >       the ‘Emacs-Lisp’ menu’s entries are two incorrect
> >       sub-menus.
> >
> >    Please let me know if anything above is unclear or if you are unable
> > to reproduce this problem.
> 
> The following may help to narrow down the problem:
> 
> In Emacs 29.4:
> I am able to reproduce the bug in Emacs GUI
> But in Emacs TTY (emacs -nw), the problem seems absent, the menu bar
> appears correct.

That could be a bug in TTY menus, or maybe a side effect of how the
menu bar is displayed there.

AFAICT, the duplicate menu is the consequence of the fact that
edebug-mode has its keymap inherit from emacs-lisp-mode:

  (defvar-keymap edebug-mode-map
    :parent emacs-lisp-mode-map

So when Edebug is activated, it wants to display yet another "Emacs
Lisp" menu on the menu bar.

Stefan, do you see a way to avoid that?

Or maybe we should not consider this a bug at all?  After all, what's
the damage?





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#71761: 29.3; Emacs-Lisp menu display is incorrect during Edebug
  2024-06-29 11:05   ` Eli Zaretskii
@ 2024-06-29 12:20     ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-29 12:47       ` Eli Zaretskii
  2024-06-30  4:12     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 7+ messages in thread
From: Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-29 12:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 71761, tpeplt, Stefan Monnier

Eli Zaretskii <eliz@gnu.org> writes:

>> >    Please let me know if anything above is unclear or if you are unable
>> > to reproduce this problem.
>> 
>> The following may help to narrow down the problem:
>> 
>> In Emacs 29.4:
>> I am able to reproduce the bug in Emacs GUI
>> But in Emacs TTY (emacs -nw), the problem seems absent, the menu bar
>> appears correct.
>
> That could be a bug in TTY menus, or maybe a side effect of how the
> menu bar is displayed there.

I fear I wasn't clear in my diagnostics.

It appears from my testing the bug is in Emacs GUI, and the TTY menus
are OK.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#71761: 29.3; Emacs-Lisp menu display is incorrect during Edebug
  2024-06-29 12:20     ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-29 12:47       ` Eli Zaretskii
  2024-06-29 22:04         ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2024-06-29 12:47 UTC (permalink / raw)
  To: Jeremy Bryant; +Cc: 71761, tpeplt, monnier

> From: Jeremy Bryant <jb@jeremybryant.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  tpeplt@gmail.com,
>   71761@debbugs.gnu.org
> Date: Sat, 29 Jun 2024 13:20:33 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >    Please let me know if anything above is unclear or if you are unable
> >> > to reproduce this problem.
> >> 
> >> The following may help to narrow down the problem:
> >> 
> >> In Emacs 29.4:
> >> I am able to reproduce the bug in Emacs GUI
> >> But in Emacs TTY (emacs -nw), the problem seems absent, the menu bar
> >> appears correct.
> >
> > That could be a bug in TTY menus, or maybe a side effect of how the
> > menu bar is displayed there.
> 
> I fear I wasn't clear in my diagnostics.
> 
> It appears from my testing the bug is in Emacs GUI, and the TTY menus
> are OK.

I understood that.  But are you aware of the fact that TTY menus use
the same code from xmenu.c that the X build without toolkits uses?

My point is that the fact that TTY menus don't show this problem is
because there's a bug in xmenu.c which somehow hides this problem.
After all, when the code which traverses the menu structures finds a
menu item that already exists, it could start a new pane or it could
overwrite the existing one.  Which one is the buggy one?






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#71761: 29.3; Emacs-Lisp menu display is incorrect during Edebug
  2024-06-29 12:47       ` Eli Zaretskii
@ 2024-06-29 22:04         ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 7+ messages in thread
From: Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-29 22:04 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 71761, tpeplt, monnier

Eli Zaretskii <eliz@gnu.org> writes:

>> > That could be a bug in TTY menus, or maybe a side effect of how the
>> > menu bar is displayed there.
>> 
>> I fear I wasn't clear in my diagnostics.
>> 
>> It appears from my testing the bug is in Emacs GUI, and the TTY menus
>> are OK.
>
> I understood that.  But are you aware of the fact that TTY menus use
> the same code from xmenu.c that the X build without toolkits uses?
>
> My point is that the fact that TTY menus don't show this problem is
> because there's a bug in xmenu.c which somehow hides this problem.
> After all, when the code which traverses the menu structures finds a
> menu item that already exists, it could start a new pane or it could
> overwrite the existing one.  Which one is the buggy one?

Interesting (glad to hear my testing was understood properly.).

I wasn't aware of this, thanks for explaining the code structure.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#71761: 29.3; Emacs-Lisp menu display is incorrect during Edebug
  2024-06-29 11:05   ` Eli Zaretskii
  2024-06-29 12:20     ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-30  4:12     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 0 replies; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-30  4:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Jeremy Bryant, 71761, tpeplt

> AFAICT, the duplicate menu is the consequence of the fact that
> edebug-mode has its keymap inherit from emacs-lisp-mode:
>
>   (defvar-keymap edebug-mode-map
>     :parent emacs-lisp-mode-map
>
> So when Edebug is activated, it wants to display yet another "Emacs
> Lisp" menu on the menu bar.

Yup, it's a longstanding problem.  E.g. we don't really have a way for
major/minor mode keymaps to *add* elements to an existing menu.

> Stefan, do you see a way to avoid that?

I think `keymap-canonicalize` is the place where we could try to handle
that, but IIRC the menu code doesn't really use it, and for "good"
reasons: we can't really take all the active keymaps and merge them into
a single canonicalized keymap because it's hard for such a merge to be
both semantically correct at the same time as providing elements in the
expected visual order (e.g. the ordering of top-level menus would
naturally be in the order of priority of the keymaps from where they
come, which would put minor mode menus at the top-left, followed by
major mode menus followed by global menus, whereas we want the exact
opposite ordering visually).


        Stefan






^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-06-30  4:12 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-24 20:32 bug#71761: 29.3; Emacs-Lisp menu display is incorrect during Edebug tpeplt
2024-06-28 18:10 ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-29 11:05   ` Eli Zaretskii
2024-06-29 12:20     ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-29 12:47       ` Eli Zaretskii
2024-06-29 22:04         ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-30  4:12     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).