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

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

[Dima Kogan]

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.

Thanks

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

[Eli Zaretskii]

merge 61162 61271
thanks

> From: Dima Kogan <dkogan@debian.org>
> 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.

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

[Dima Kogan]

Hi Eli.

Thanks for the pointer. I just tried out M-x gdb instead of M-x gud-gdb
as you suggested here. It appears to have the same issue though: RET in
the buffer being debugged reports the same error. And it still looks
like it's using gud internally. f1-m says:

  The major mode is Debugger mode defined in gud.el:

Is this right? I'm seeing this with 'emacs -Q'. This build is a few
weeks old, so maybe this is addressed in the latest release? I'm using a
build from 2023/01/25 at 8b87d095acf.

Thanks

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

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: Dima Kogan <dkogan@debian.org>, 61271@debbugs.gnu.org
> Date: Tue, 14 Feb 2023 15:38:28 -0800
> 
> Thanks for the pointer. I just tried out M-x gdb instead of M-x gud-gdb
> as you suggested here. It appears to have the same issue though: RET in
> the buffer being debugged reports the same error. And it still looks
> like it's using gud internally. f1-m says:
> 
>   The major mode is Debugger mode defined in gud.el:

I didn't say switching to "M-x gdb" will solve this particular
problem.  See the rest of my original response: this is a known issue
on master.  Until we find a way to fix that, I suggest to either stay
with emacs-29 or make your local changes on master like we did on
emacs-29 with commits 3623d5c195 and 641ef36403.