GNU bug report logs - #61162
30.0.50; RET in source files that are being displayed by gud no longer works

Previous Next

Full log

View this message in rfc822 format

From: Michael Welsh Duggan <mwd <at> md5i.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>, 61162 <at> debbugs.gnu.org
Subject: bug#61162: 30.0.50; RET in source files that are being displayed by gud no longer works
Date: Tue, 31 Jan 2023 15:18:15 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Welsh Duggan <mwd <at> md5i.com>
>> Date: Tue, 31 Jan 2023 14:17:20 -0500
>> 
>> Michael Welsh Duggan <mwd <at> md5i.com> writes:
>> 
>> > Create a trivial C program.  Here's a good example:
>> >
>> >     int main()
>> >     {
>> >       return 0;
>> >     }
>> >
>> > Save it as foo.c, and compile it with debugging:
>> >
>> >     gcc -ggdb3 -o foo foo.c
>> >
>> > From emacs -Q, start gdb on foo:
>> >
>> >     M-x gud-gdb RET 
>> >
>> > In my case, since foo is the only executable in the dir, the command
>> > line for gdb is already set up correctly as:
>> >
>> >     gdb --fullname foo
>> >
>> > Hit RET.  You should be at the gdb prompt.  Start the program:
>> >
>> >     start RET
>> >
>> > You should now get another window with foo.c in it for context.  Switch
>> > to that buffer and type RET.
>> >
>> >     C-x o
>> >     RET
>> >
>> > In my case, I get:
>> >
>> >     comint-send-input: Current buffer has no process
>> >
>> > This is new and broken behavior.  The expected behavior is that a
>> > newline is inserted in the buffer.
>> 
>> This appears to be caused by commit
>> a7b0b20c1bc758fa99fda96d06a266868aec3eea, which was supposed to fix
>> Bug#59605.
>
> This current problem is part of fallout from commit 8bb5c1bfec.  That
> commit was reverted on the emacs-29 branch, as it caused too much
> trouble.  It was not reverted on master, as I still hope someone
> motivated enough will step up to fix this without reverting back to
> using easy-mmode, which we hoped to obsolete.

I'll try to look into that, but it might be beyond me.

> If you can find a fix on master, patches would be very welcome.
> Failing that, I might eventually decide to revert that commit on
> master as well.  There's a limit to the efforts I'm prepared to sink
> into maintaining what is basically an obsolete package which uses a
> GDB feature that GDB developers consider obsolete and may remove any
> day (why don't you use "M-x gdb" instead?).

I always use "M-x gud-gdb" because, historically, "M-x gdb" didn't
support multiple simultaneous gdb sessions.  If this is no longer the
case, I will see if I can change my habits.

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.