GNU bug report logs -
#71761
29.3; Emacs-Lisp menu display is incorrect during Edebug
Previous Next
To reply to this bug, email your comments to 71761 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71761
; Package
emacs
.
(Mon, 24 Jun 2024 20:33:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
tpeplt <tpeplt <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 24 Jun 2024 20:33:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71761
; Package
emacs
.
(Fri, 28 Jun 2024 18:11:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 71761 <at> debbugs.gnu.org (full text, mbox):
tpeplt <tpeplt <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71761
; Package
emacs
.
(Sat, 29 Jun 2024 11:06:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 71761 <at> debbugs.gnu.org (full text, mbox):
> Cc: 71761 <at> 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 <at> gnu.org>
>
> tpeplt <tpeplt <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71761
; Package
emacs
.
(Sat, 29 Jun 2024 12:22:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 71761 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71761
; Package
emacs
.
(Sat, 29 Jun 2024 12:48:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 71761 <at> debbugs.gnu.org (full text, mbox):
> From: Jeremy Bryant <jb <at> jeremybryant.net>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, tpeplt <at> gmail.com,
> 71761 <at> debbugs.gnu.org
> Date: Sat, 29 Jun 2024 13:20:33 +0100
>
> Eli Zaretskii <eliz <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71761
; Package
emacs
.
(Sat, 29 Jun 2024 22:05:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 71761 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71761
; Package
emacs
.
(Sun, 30 Jun 2024 04:13:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 71761 <at> debbugs.gnu.org (full text, mbox):
> 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
This bug report was last modified 69 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.