[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer
From: |
Eli Zaretskii |
Subject: |
bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer |
Date: |
Thu, 09 Mar 2023 20:14:42 +0200 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 62041@debbugs.gnu.org, larsi@gnus.org
> Date: Thu, 09 Mar 2023 12:59:59 -0500
>
> > However, the fix is incomplete AFAICT: the "pseudo-toolbar" which
> > gdb-mi.el should show on TTY frames was lost.
>
> Hmm... I must say I'm stumped: I have no idea where this pseudo-tool-bar
> comes from in `emacs-29`. Any hint?
I think it comes from gud-tool-bar-map. gdb-get-buffer-create has
this:
(setq-local tool-bar-map gud-tool-bar-map)
> > Please compare the display in "M-x gdb" in a TTY session between
> > emacs-29 and master: the former shows a kind of "text-mode tool bar"
> > on the menu-bar line when you are in the GUD buffer,
>
> Indeed, I see it. I'm unable to make use of it, OTOH. I tried to
> enable/disable `xt-mouse-mode` but that didn't help: clicking on those
> entries seems to do nothing at all (and `C-h k` also just tells me).
> I also noticed that F10 fails to "unroll" the menus in those buffers
> where there is this funny pseudo-tool-bar.
It works with a real mouse (here on MS-Windows, and I believe also
with GPM). If xt-mouse-mode doesn't work with it, I guess it's some
bug.
> > and also if you are in a source buffer when
> > a gdb-mi session is active. These "pseudo-toolbar" buttons are useful
> > if you have a mouse on a TTY terminal: you can click on these
> > "buttons" , and they work like the real tool bar on GUI frames.
>
> I can click on the menu entries to "unroll" the corresponding menu, but
> clicking on those pseudo-tool-bar thingies doesn't seem to do anything
> at all (nothing in the echo area or in *Messages* either).
It does here: if I click on "next", execution moves by one source
line.
> The disappearance of the pseudo-tool-bar affects both `gud-minor-mode`
> and `gud-mode` buffers, so I think it's not directly related to the
> sharing between those two keymaps.
>
> IOW, I think this is a different bug.
Maybe.
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Stefan Monnier, 2023/03/07
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Eli Zaretskii, 2023/03/08
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Stefan Monnier, 2023/03/08
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Stefan Monnier, 2023/03/08
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Eli Zaretskii, 2023/03/09
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Stefan Monnier, 2023/03/09
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Stefan Monnier, 2023/03/09
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer,
Eli Zaretskii <=
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Eli Zaretskii, 2023/03/09
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Stefan Monnier, 2023/03/09
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Stefan Monnier, 2023/03/09
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Eli Zaretskii, 2023/03/10
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Stefan Monnier, 2023/03/10
- bug#62041: 30.0.50; RET bound to `comint-send-input` in C-mode buffer, Eli Zaretskii, 2023/03/11