Subject: Re: bug#61271: 30.0.50; gud makes source files un-editable

From: Eli Zaretskii <[email-masked]>
Date: Sat, 04 Feb 2023 10:58:18 +0200

merge 61162 61271
thanks

> From: Dima Kogan <[email-masked]>
> Date: Fri, 03 Feb 2023 12:07:22 -0800
> 
> Hi. I'm using a bleeding edge build of emacs from git. This issue is
> recent: probably a few weeks old at most. Recipe:
> 
> 1. Create any debuggable C program. For instance I just made a
>    tst.c:
> 
>      int main(int argc, char* argv[])
>      {
>          return 0;
>      }
> 
>    And I built it like this:
> 
>      gcc -g -o tst tst.c
> 
> 2. emacs -Q tst.c
> 
> 3. M-x gud-gdb ... gdb --fullname tst
> 
> 4. b main
> 
> 5. r
> 
>    We're now debugging the executable tst, and we're at a breakpoint in
>    tst.c. emacs should show the breakpoint in the tst.c buffer
> 
> 6. Switch to the tst.c buffer
> 
> 7. Press RET
> 
> tst.c is a source buffer. "RET" should insert a newline. Instead emacs
> throws an error
> 
>   comint-send-input: Current buffer has no process
> 
> Pressing f1-b I see that tst.c is in gud-minor-mode (although this
> doesn't show up in f1-m for some reason). This mode defines the RET
> binding, and is the source of this problem.

This is a duplicate of bug#61162.  If no one comes with a better
solution, I will at some point revert on master the change whose
fallout causes this (it was already reverted on emacs-29, but not on
master, since I still hope someone will have an idea how to fix that
properly).

However, in general I suggest to switch to using "M-x gdb" instead of
"M-x gud-gdb", since the latter uses deprecated capabilities of GDB
itself, and can stop working any day, if the GDB developers decide to
remove those capabilities.