GNU bug report logs - #21777
25.0.50; gud-gdb uses a pager, which is harmful inside emacs

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21777 in the body.
You can then email your comments to 21777 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs
Date: Wed, 28 Oct 2015 12:20:45 -0700

Hi. A regression occurred since 24.4.1, and gud-gdb now uses the pager
by default. This means that when gdb wants to output more than N lines,
it says

   ---Type <return> to continue, or q <return> to quit---

This is intended for gdb running in the console, but makes using gdb
from emacs much less pleasant since extra user interaction becomes
necessary. At worst, gdb sessions meant to be non-interactive (ones that
have self-continuing breakpoint commands for instance) become forcefully
interactive.


Recipe:

1. emacs -Q
2. M-x gud-gdb (select any executable; it doesn't matter)
3. gdb command: show height

Emacs 24.4.1 says

    (gdb) show height
    Number of lines gdb thinks are in a page is unlimited.

This is good. The pager is off, and emacs will receive all gdb output
without extra user interaction.

Emacs from git says

    (gdb) show height
    Number of lines gdb thinks are in a page is 24.

This is bad. After 24 lines of output gdb will pester the user. I
haven't attempted to do any debugging here yet. Probably will look at it
eventually, but if somebody knows what's wrong immediately, that'd be
great

Message #8 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 21777 <at> debbugs.gnu.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Wed, 28 Oct 2015 23:27:58 +0100

Dima Kogan <dima <at> secretsauce.net> writes:

> Emacs from git says
>
>     (gdb) show height
>     Number of lines gdb thinks are in a page is 24.

This is something that needs to be fixed in gdb, see init_page_info in
gdb/utils.c.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #11 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 21777 <at> debbugs.gnu.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Wed, 28 Oct 2015 15:57:37 -0700

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> Dima Kogan <dima <at> secretsauce.net> writes:
>
>> Emacs from git says
>>
>>     (gdb) show height
>>     Number of lines gdb thinks are in a page is 24.
>
> This is something that needs to be fixed in gdb, see init_page_info in
> gdb/utils.c.

Hi. Thanks for replying. Looking at gdb/utils.c, apparently gdb looks at
the EMACS environment variable, which was set previously but is not
anymore:

  https://github.com/emacs-mirror/emacs/commit/beaab898968caf8b243a33d24824d430fabc31fc

This patch in emacs is what broke it. Options:

1. revert above patch
2. patch gdb to look at INSIDE_EMACS not EMACS
3. handle this inside emacs, not relying on gdb behavior

I like 3. Emacs should be responsible for things emacs wants, not
external applications, even if they're GNU applications.

Also, it looks like gdb checks EMACS in a few more places, and I haven't
looked at those yet.

Thoughts?

Message #14 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Thu, 29 Oct 2015 18:16:02 +0200

> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Wed, 28 Oct 2015 15:57:37 -0700
> Cc: 21777 <at> debbugs.gnu.org
> 
> Hi. Thanks for replying. Looking at gdb/utils.c, apparently gdb looks at
> the EMACS environment variable, which was set previously but is not
> anymore:
> 
> https://github.com/emacs-mirror/emacs/commit/beaab898968caf8b243a33d24824d430fabc31fc
> 
> This patch in emacs is what broke it. Options:
> 
> 1. revert above patch

That patch fixed a real-life bug, so I don't think reverting it is an
option we should seriously consider.

> 2. patch gdb to look at INSIDE_EMACS not EMACS

That should be done regardless, I will submit a patch to GDB.

> 3. handle this inside emacs, not relying on gdb behavior
> 
> I like 3. Emacs should be responsible for things emacs wants, not
> external applications, even if they're GNU applications.

3 is okay in principle, but you didn't show any specific suggestions.
What did you have in mind?

Please also keep in mind that "M-x gud-gdb" is a legacy command, and
the more modern "M-x gdb" doesn't have that problem.

There's also:

 4. Fix this locally in your GDB init files (using GDB scripting
    facilities).

> Also, it looks like gdb checks EMACS in a few more places, and I haven't
> looked at those yet.

Maybe I'm missing something, but I don't see any additional places
except the one pointed out by Andreas.

Message #17 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Thu, 29 Oct 2015 15:58:46 -0700

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

>> From: Dima Kogan <dima <at> secretsauce.net>
>>
>> Hi. Thanks for replying. Looking at gdb/utils.c, apparently gdb looks at
>> the EMACS environment variable, which was set previously but is not
>> anymore:
>> 
>> 2. patch gdb to look at INSIDE_EMACS not EMACS
>
> That should be done regardless, I will submit a patch to GDB.

Thanks for doing that!


>> 3. handle this inside emacs, not relying on gdb behavior
>> 
>> I like 3. Emacs should be responsible for things emacs wants, not
>> external applications, even if they're GNU applications.
>
> 3 is okay in principle, but you didn't show any specific suggestions.
> What did you have in mind?

gud-gdb.el can send a "set height unlimited" command when it starts the
gdb process. I'm happy to give you a patch, if you want.


> Please also keep in mind that "M-x gud-gdb" is a legacy command, and
> the more modern "M-x gdb" doesn't have that problem.

I didn't like it when I tried it the last time; don't remember what
specifically was the problem. But if we're still shipping gud-gdb, it
should work properly, I think.


> There's also:
>
>  4. Fix this locally in your GDB init files (using GDB scripting
>     facilities).

But then it'll annoy others.


>> Also, it looks like gdb checks EMACS in a few more places, and I haven't
>> looked at those yet.
>
> Maybe I'm missing something, but I don't see any additional places
> except the one pointed out by Andreas.

You're right. I was looking at the readline in their tree, but that's
unrelated.

Message #20 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Thu, 29 Oct 2015 20:43:35 -0700

Dima Kogan <dima <at> secretsauce.net> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Dima Kogan <dima <at> secretsauce.net>
>>>
>>> 3. handle this inside emacs, not relying on gdb behavior
>> 
>> 3 is okay in principle, but you didn't show any specific suggestions.
>> What did you have in mind?
>
> gud-gdb.el can send a "set height unlimited" command when it starts the
> gdb process. I'm happy to give you a patch, if you want.

Something like this:

---------------------------------------------------------------------------
diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el
index 9ab0667..61ae85c 100644
--- a/lisp/progmodes/gud.el
+++ b/lisp/progmodes/gud.el
@@ -785,6 +785,8 @@ directory and source-file directory for your debugger."
   (setq gdb-first-prompt t)
   (setq gud-running nil)
   (setq gud-filter-pending-text nil)
+
+  (gud-basic-call "set height unlimited")
   (run-hooks 'gud-gdb-mode-hook))
 
 ;; The completion process filter indicates when it is finished.
---------------------------------------------------------------------------


This works. The main issue is that it creates an extra "(gdb)" prompt
we'd want to suppress. You get the idea, however.

Message #23 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Fri, 30 Oct 2015 09:54:57 +0200

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: schwab <at> linux-m68k.org, 21777 <at> debbugs.gnu.org
> Date: Thu, 29 Oct 2015 15:58:46 -0700
> 
> >> 2. patch gdb to look at INSIDE_EMACS not EMACS
> >
> > That should be done regardless, I will submit a patch to GDB.
> 
> Thanks for doing that!

The patch is already in the GDB repository.

> >> 3. handle this inside emacs, not relying on gdb behavior
> >> 
> >> I like 3. Emacs should be responsible for things emacs wants, not
> >> external applications, even if they're GNU applications.
> >
> > 3 is okay in principle, but you didn't show any specific suggestions.
> > What did you have in mind?
> 
> gud-gdb.el can send a "set height unlimited" command when it starts the
> gdb process. I'm happy to give you a patch, if you want.

Please do, but this should be done so as not to disable any "set
height" commands in the init files that GDB reads when it starts.
Otherwise users who do want to set that option for some reason will
crucify us.  If this becomes tricky, the only reasonable way out might
be a user option which defaults to off.

Thanks.

Message #26 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Fri, 30 Oct 2015 10:17:10 +0200

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: schwab <at> linux-m68k.org, 21777 <at> debbugs.gnu.org
> Date: Thu, 29 Oct 2015 20:43:35 -0700
> 
> ---------------------------------------------------------------------------
> diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el
> index 9ab0667..61ae85c 100644
> --- a/lisp/progmodes/gud.el
> +++ b/lisp/progmodes/gud.el
> @@ -785,6 +785,8 @@ directory and source-file directory for your debugger."
>    (setq gdb-first-prompt t)
>    (setq gud-running nil)
>    (setq gud-filter-pending-text nil)
> +
> +  (gud-basic-call "set height unlimited")
>    (run-hooks 'gud-gdb-mode-hook))
>  
>  ;; The completion process filter indicates when it is finished.
> ---------------------------------------------------------------------------
> 
> 
> This works. The main issue is that it creates an extra "(gdb)" prompt
> we'd want to suppress. You get the idea, however.

What if the user has "set height 100" in their ~/.gdbinit, or in the
system-wide gdbinit file?  Will those settings be overridden?  If so,
we cannot fix the problem this way, not by default anyway.

Thanks.

Message #29 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Fri, 30 Oct 2015 02:13:02 -0700

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

> What if the user has "set height 100" in their ~/.gdbinit, or in the
> system-wide gdbinit file? Will those settings be overridden? If so, we
> cannot fix the problem this way, not by default anyway.

Yes. This overrides any user settings. I really can't imagine why
somebody would want a pager inside emacs, but maybe I just need more
imagination.

What is more likely I think is that somebody would have a "set height N"
in their .gdbinit, intending it to be picked up during console gdb use,
and that this somebody would be annoyed that this setting persists when
using gdb through gud. That somebody would want a different setting for
the two use cases, which is not easily done, currently.

So I'm in favor of overriding the user defaults here. Otherwise, how
about this:

- we have a variable 'gud-gdb-set-height-unlimited',
  which has 3 states: uninitialized, yes, no

- when gud starts up, if it's 'uninitialized', we ask the user if they
  want to override, and whether to do so in the future; if they say yes,
  we update their .emacs.d/init.el. narrow-to-region has this type of
  user querying. We override only if it's 'yes'

This would take care of it, but a desire to have a pager inside gud
sounds so crazy to me, that I'd rather just force it.

What do we do for vc-mode interaction with git? It has a similar
situation where a user can configure git to use a pager. But in that
case we completely override that setting, don't we? If so, that would be
a precedent to handle gdb in the same way.

Message #32 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Fri, 30 Oct 2015 11:32:47 +0200

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: schwab <at> linux-m68k.org, 21777 <at> debbugs.gnu.org
> Date: Fri, 30 Oct 2015 02:13:02 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > What if the user has "set height 100" in their ~/.gdbinit, or in the
> > system-wide gdbinit file? Will those settings be overridden? If so, we
> > cannot fix the problem this way, not by default anyway.
> 
> Yes. This overrides any user settings. I really can't imagine why
> somebody would want a pager inside emacs, but maybe I just need more
> imagination.

IME, users sometimes have some use cases that look really weird to me,
but are somehow very important to them.  So I'm trying to avoid
stepping on their toes as much as possible, even if I cannot imagine
those use cases in advance.

> So I'm in favor of overriding the user defaults here. Otherwise, how
> about this:
> 
> - we have a variable 'gud-gdb-set-height-unlimited',
>   which has 3 states: uninitialized, yes, no
> 
> - when gud starts up, if it's 'uninitialized', we ask the user if they
>   want to override, and whether to do so in the future; if they say yes,
>   we update their .emacs.d/init.el. narrow-to-region has this type of
>   user querying. We override only if it's 'yes'

Why not a simpler boolean, off by default?  This problem will go away
soon enough, so maybe solutions that are too complicated would be
over-engineering it?

Btw, does gud.el know the version of GDB it runs?  If so, this option
should be a no-op for GDB 7.11 and later.

> What do we do for vc-mode interaction with git? It has a similar
> situation where a user can configure git to use a pager. But in that
> case we completely override that setting, don't we? If so, that would be
> a precedent to handle gdb in the same way.

In vc-git.el, we don't present a CLI-like interface to Git, we just
consume all the Git output and then process it.  So the situation
there is slightly different, I think.  But I will let other chime in
and express their opinions.

Thanks.

Message #35 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: dima <at> secretsauce.net
Cc: 21777 <at> debbugs.gnu.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Fri, 30 Oct 2015 16:01:01 +0200

> Date: Fri, 30 Oct 2015 11:32:47 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
> 
> > - we have a variable 'gud-gdb-set-height-unlimited',
> >   which has 3 states: uninitialized, yes, no
> > 
> > - when gud starts up, if it's 'uninitialized', we ask the user if they
> >   want to override, and whether to do so in the future; if they say yes,
> >   we update their .emacs.d/init.el. narrow-to-region has this type of
> >   user querying. We override only if it's 'yes'
> 
> Why not a simpler boolean, off by default?  This problem will go away
> soon enough, so maybe solutions that are too complicated would be
> over-engineering it?

I think if we have such an option, and it's by default off, we might
consider not bothering about gdbinit commands that contradict the
effect of that option.  The option gives users enough power to decide
what they want more.

WDYT?

Message #38 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Fri, 30 Oct 2015 12:05:54 -0700

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

>> Date: Fri, 30 Oct 2015 11:32:47 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
>> 
>> > - we have a variable 'gud-gdb-set-height-unlimited',
>> >   which has 3 states: uninitialized, yes, no
>> > 
>> > - when gud starts up, if it's 'uninitialized', we ask the user if they
>> >   want to override, and whether to do so in the future; if they say yes,
>> >   we update their .emacs.d/init.el. narrow-to-region has this type of
>> >   user querying. We override only if it's 'yes'
>> 
>> Why not a simpler boolean, off by default?  This problem will go away
>> soon enough, so maybe solutions that are too complicated would be
>> over-engineering it?

You need a third state to know whether to pester the user or not


> I think if we have such an option, and it's by default off, we might
> consider not bothering about gdbinit commands that contradict the
> effect of that option.  The option gives users enough power to decide
> what they want more.

Right. This was the idea. I'll send a patch at some point. Not today.

Thanks

Message #41 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 21777 <at> debbugs.gnu.org
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Fri, 30 Oct 2015 22:34:25 +0200

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: 21777 <at> debbugs.gnu.org
> Date: Fri, 30 Oct 2015 12:05:54 -0700
> 
> >> > - when gud starts up, if it's 'uninitialized', we ask the user if they
> >> >   want to override, and whether to do so in the future; if they say yes,
> >> >   we update their .emacs.d/init.el. narrow-to-region has this type of
> >> >   user querying. We override only if it's 'yes'
> >> 
> >> Why not a simpler boolean, off by default?  This problem will go away
> >> soon enough, so maybe solutions that are too complicated would be
> >> over-engineering it?
> 
> You need a third state to know whether to pester the user or not

Why pester them?  Let's rely on them to know what to do, or ask.

> > I think if we have such an option, and it's by default off, we might
> > consider not bothering about gdbinit commands that contradict the
> > effect of that option.  The option gives users enough power to decide
> > what they want more.
> 
> Right. This was the idea. I'll send a patch at some point. Not today.

There's no rush.  Thanks in advance.

Message #44 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, Dima Kogan <dima <at> secretsauce.net>
Subject: Re: bug#21777: 25.0.50;
 gud-gdb uses a pager, which is harmful inside emacs
Date: Sun, 29 Sep 2019 23:49:08 +0200

Dima Kogan <dima <at> secretsauce.net> writes:

>> I think if we have such an option, and it's by default off, we might
>> consider not bothering about gdbinit commands that contradict the
>> effect of that option.  The option gives users enough power to decide
>> what they want more.
>
> Right. This was the idea. I'll send a patch at some point. Not today.

Hi Dima,

That was almost 4 years ago.  Did you ever get around to writing that patch?

Best regards,
Stefan Kangas

Message #47 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org,
 Dima Kogan <dima <at> secretsauce.net>
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Sun, 20 Sep 2020 23:18:32 +0200

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

> IME, users sometimes have some use cases that look really weird to me,
> but are somehow very important to them.  So I'm trying to avoid
> stepping on their toes as much as possible, even if I cannot imagine
> those use cases in advance.

I worked up a patch for this, but in testing, there's a number of
problems.

1) When resizing a frame, the height in gdb is overwritten.  Where does
that come from?  I tried grepping, but couldn't find anything.

2) Sending a command this way to gdb gives us an extra prompt, which
isn't nice.

3) If you start gdb with M-x gdb instead of M-x gud-gdb, the height
variable in gdb is always switched off:

  (gdb-input "-gdb-set height 0" 'ignore)

So why shouldn't gud-gdb do the same thing?

diff --git a/doc/emacs/building.texi b/doc/emacs/building.texi
index 7074bd45d7..ac54c570cd 100644
--- a/doc/emacs/building.texi
+++ b/doc/emacs/building.texi
@@ -1040,6 +1040,15 @@ GDB User Interface Layout
 need to check that the breakpoints in recently edited source files are
 still in the right places.
 
+@vindex gud-pager-height
+  GDB normally uses a pager when displaying output (like backtraces).
+This can be inconvenient when running inside Emacs, so the default
+value of @code{gud-pager-height} is @code{unlimited}, meaning that the
+pager is disabled.  This variable can also be a number (which is used
+as the number of lines by the pager), or @code{nil}, meaning that the
+pager setting shouldn't be changed from the gdb defaults (or
+@file{.gdbinit} settings).
+
 @node Source Buffers
 @subsubsection Source Buffers
 @cindex fringes, for debugging
diff --git a/etc/NEWS b/etc/NEWS
index 1f52341ae4..3014eddbdd 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1034,6 +1034,10 @@ window after starting).  This variable defaults to nil.
 
 ** Miscellaneous
 
+*** New user option 'gud-pager-height'
+This variable is used to set up the gdb pager, and defaults to
+`unlimited', meaning that a pager won't be used.
+
 +++
 *** Interactive regular expression search now uses faces for sub-groups.
 E.g., 'C-M-s foo-\([0-9]+\)' will now use the 'isearch-group-1' face
diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el
index 84c473ddb7..7acc540b01 100644
--- a/lisp/progmodes/gud.el
+++ b/lisp/progmodes/gud.el
@@ -67,6 +67,19 @@ gud-key-prefix
   :type 'key-sequence
   :group 'gud)
 
+(defcustom gud-pager-height 'unlimited
+  "The size of a page when gdb displays output.
+gdb normally uses a pager when displaying things like
+backtraces (or other things that take a lot of room).  This
+variable allows customizing the pager when gdb is run from Emacs.
+
+This can be a number (the number of lines), `unlimited' (don't
+use the pager at all), or nil (don't change the defaults)."
+  :type '(choice (const :tag "No paging" unlimited)
+                 integer
+                 (const :tag "Don't set" nil))
+  :version "28.1")
+
 (global-set-key (vconcat gud-key-prefix "\C-l") 'gud-refresh)
 ;; (define-key ctl-x-map " " 'gud-break); backward compatibility hack
 
@@ -796,6 +809,9 @@ gud-gdb
   (setq gdb-first-prompt t)
   (setq gud-running nil)
   (setq gud-filter-pending-text nil)
+
+  (when gud-pager-height
+    (gud-basic-call (format "set height %s" gud-pager-height)))
   (run-hooks 'gud-gdb-mode-hook))
 
 ;; The completion process filter indicates when it is finished.


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #50 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Mon, 21 Sep 2020 17:03:53 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Dima Kogan <dima <at> secretsauce.net>,  21777 <at> debbugs.gnu.org,
>   schwab <at> linux-m68k.org
> Date: Sun, 20 Sep 2020 23:18:32 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > IME, users sometimes have some use cases that look really weird to me,
> > but are somehow very important to them.  So I'm trying to avoid
> > stepping on their toes as much as possible, even if I cannot imagine
> > those use cases in advance.
> 
> I worked up a patch for this, but in testing, there's a number of
> problems.

Do you see the original problem with a recent version of GDB?  In the
discussion, I mentioned that the change to follow that of Emacs was
installed in GDB back then, so it's reasonable to expect that we no
longer have a problem described in this bug report.

Message #53 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Mon, 21 Sep 2020 16:07:06 +0200

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

>> I worked up a patch for this, but in testing, there's a number of
>> problems.
>
> Do you see the original problem with a recent version of GDB?  In the
> discussion, I mentioned that the change to follow that of Emacs was
> installed in GDB back then, so it's reasonable to expect that we no
> longer have a problem described in this bug report.

No, the problem is still there -- If you say `M-x gud-gdb' and then
issue a backtrace, then the gdb pager kicks in.

(This problem is not present in `M-x gdb', which tells gdb to switch the
pager off when it starts gdb.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #56 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Tue, 22 Sep 2020 18:46:19 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: dima <at> secretsauce.net,  21777 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org
> Date: Mon, 21 Sep 2020 16:07:06 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> I worked up a patch for this, but in testing, there's a number of
> >> problems.
> >
> > Do you see the original problem with a recent version of GDB?  In the
> > discussion, I mentioned that the change to follow that of Emacs was
> > installed in GDB back then, so it's reasonable to expect that we no
> > longer have a problem described in this bug report.
> 
> No, the problem is still there -- If you say `M-x gud-gdb' and then
> issue a backtrace, then the gdb pager kicks in.

This is very strange.  I clearly see in GDB the code to set unlimited
page height.  Any GDB version later than 7.10 should have this.

If you invoke "M-x gud-gdb", then type "show height" at the "(gdb)"
prompt in the interaction buffer, what do you see?

And if you then type "show environment INSIDE_EMACS" at the "(gdb)"
prompt, what do you see?

Message #59 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Tue, 22 Sep 2020 17:51:20 +0200

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

>> No, the problem is still there -- If you say `M-x gud-gdb' and then
>> issue a backtrace, then the gdb pager kicks in.
>
> This is very strange.  I clearly see in GDB the code to set unlimited
> page height.  Any GDB version later than 7.10 should have this.
>
> If you invoke "M-x gud-gdb", then type "show height" at the "(gdb)"
> prompt in the interaction buffer, what do you see?
>
> And if you then type "show environment INSIDE_EMACS" at the "(gdb)"
> prompt, what do you see?

Aha!

(gdb) show height
Number of lines gdb thinks are in a page is unlimited.
(gdb) show environment INSIDE_EMACS
INSIDE_EMACS = 28.0.50,comint

It is indeed unlimited...  but if I change the size of the frame:

(gdb) show height
Number of lines gdb thinks are in a page is 35.

So Emacs is somehow telling gdb to set the height when the frame size
changes.  I tried grepping for that yesterday, but I was unable to see
what triggers that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #62 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 21777 <at> debbugs.gnu.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Tue, 22 Sep 2020 17:57:18 +0200

On Sep 22 2020, Lars Ingebrigtsen wrote:

> So Emacs is somehow telling gdb to set the height when the frame size
> changes.  I tried grepping for that yesterday, but I was unable to see
> what triggers that.

It's the normal SIGWINCH handling.  Works the same in any resizable
terminal.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #65 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Tue, 22 Sep 2020 19:09:02 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: dima <at> secretsauce.net,  21777 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org
> Date: Tue, 22 Sep 2020 17:51:20 +0200
> 
> (gdb) show height
> Number of lines gdb thinks are in a page is unlimited.
> (gdb) show environment INSIDE_EMACS
> INSIDE_EMACS = 28.0.50,comint
> 
> It is indeed unlimited...  but if I change the size of the frame:
> 
> (gdb) show height
> Number of lines gdb thinks are in a page is 35.
> 
> So Emacs is somehow telling gdb to set the height when the frame size
> changes.  I tried grepping for that yesterday, but I was unable to see
> what triggers that.

That's a different problem, then.  I think it is related to
window-adjust-process-window-size-function and
set-process-window-size, introduced in Emacs 25.  I guess gud-gdb
should disable that feature.

Message #68 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 21777 <at> debbugs.gnu.org,
 dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Tue, 22 Sep 2020 18:19:54 +0200

On Sep 22 2020, Eli Zaretskii wrote:

> That's a different problem, then.  I think it is related to
> window-adjust-process-window-size-function and
> set-process-window-size, introduced in Emacs 25.  I guess gud-gdb
> should disable that feature.

It's really a bug in gdb, as just sending SIGWINCH to gdb will trigger
this.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #71 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: larsi <at> gnus.org, 21777 <at> debbugs.gnu.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Tue, 22 Sep 2020 19:51:37 +0300

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,  dima <at> secretsauce.net,
>   21777 <at> debbugs.gnu.org
> Date: Tue, 22 Sep 2020 18:19:54 +0200
> 
> On Sep 22 2020, Eli Zaretskii wrote:
> 
> > That's a different problem, then.  I think it is related to
> > window-adjust-process-window-size-function and
> > set-process-window-size, introduced in Emacs 25.  I guess gud-gdb
> > should disable that feature.
> 
> It's really a bug in gdb, as just sending SIGWINCH to gdb will trigger
> this.

So you are saying that when INSIDE_EMACS is set, GDB should disable
the Readline's SIGWINCH handler?

Message #74 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 21777 <at> debbugs.gnu.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Tue, 22 Sep 2020 19:18:54 +0200

On Sep 22 2020, Eli Zaretskii wrote:

> So you are saying that when INSIDE_EMACS is set, GDB should disable
> the Readline's SIGWINCH handler?

No, it should never override an unlimited height setting via SIGWINCH.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #77 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: larsi <at> gnus.org, 21777 <at> debbugs.gnu.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Tue, 22 Sep 2020 20:39:58 +0300

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: larsi <at> gnus.org,  dima <at> secretsauce.net,  21777 <at> debbugs.gnu.org
> Date: Tue, 22 Sep 2020 19:18:54 +0200
> 
> On Sep 22 2020, Eli Zaretskii wrote:
> 
> > So you are saying that when INSIDE_EMACS is set, GDB should disable
> > the Readline's SIGWINCH handler?
> 
> No, it should never override an unlimited height setting via SIGWINCH.

I'm not sure I agree: how is an unlimited setting different from any
other setting?  Any setting can be overridden to replace it with a
different setting.

Anyway, this discussion belongs on the GDB mailing list, not here.

Message #80 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 21777 <at> debbugs.gnu.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Tue, 22 Sep 2020 19:46:28 +0200

On Sep 22 2020, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab <at> linux-m68k.org>
>> Cc: larsi <at> gnus.org,  dima <at> secretsauce.net,  21777 <at> debbugs.gnu.org
>> Date: Tue, 22 Sep 2020 19:18:54 +0200
>> 
>> On Sep 22 2020, Eli Zaretskii wrote:
>> 
>> > So you are saying that when INSIDE_EMACS is set, GDB should disable
>> > the Readline's SIGWINCH handler?
>> 
>> No, it should never override an unlimited height setting via SIGWINCH.
>
> I'm not sure I agree: how is an unlimited setting different from any
> other setting?

It is special, as it never matches any real terminal size.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #83 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Wed, 23 Sep 2020 14:53:53 +0200

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

> That's a different problem, then.  I think it is related to
> window-adjust-process-window-size-function and
> set-process-window-size, introduced in Emacs 25.  I guess gud-gdb
> should disable that feature.

But if the user has the pager enabled, then Emacs should notify gdb
about the size change...

Andreas Schwab <schwab <at> linux-m68k.org> writes:

>> I'm not sure I agree: how is an unlimited setting different from any
>> other setting?
>
> It is special, as it never matches any real terminal size.

Indeed.  If gdb has disabled the pager, then Emacs telling gdb about the
changed size shouldn't enable the pager.

But I'm still not sure this is actually what is going on, because I'm
just not finding exactly where this happens.  For instance,
`window--adjust-process-windows' is never called in buffers started with
`M-x gud-gdb'...  and adjusting the frame size in a buffer started with
`M-x gdb' does not make gdb switch the pager on.  

And debug-on-entry on set-process-window-size isn't triggered, either.

Grepping for SIGWINCH doesn't immediately give me any clues, either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #86 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Wed, 23 Sep 2020 17:41:06 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: dima <at> secretsauce.net,  21777 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org
> Date: Wed, 23 Sep 2020 14:53:53 +0200
> 
> But I'm still not sure this is actually what is going on, because I'm
> just not finding exactly where this happens.  For instance,
> `window--adjust-process-windows' is never called in buffers started with
> `M-x gud-gdb'...  and adjusting the frame size in a buffer started with
> `M-x gdb' does not make gdb switch the pager on.  

The value of window-adjust-process-window-size-function in the GUD
buffer is window-adjust-process-window-size-smallest.  Did you try to
trace that function?

> Grepping for SIGWINCH doesn't immediately give me any clues, either.

We don't send SIGWINCH, we use IOCTL, AFAIR.

Message #89 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Thu, 24 Sep 2020 16:15:29 +0200

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

> The value of window-adjust-process-window-size-function in the GUD
> buffer is window-adjust-process-window-size-smallest.  Did you try to
> trace that function?

I tried that now, and debug-on-entry-ing that function does not result
in that function giving a backtrace...

AAARGH!  It's, once again, the problem of the debugger not being allowed
to be called when inhibit-redisplay is bound, which is seems to be
here.  I wish we could fix that, or at least have `debug' say "Not
entering the debugger because inhibit-redisplay is set"...

Anyway, set-process-window-size is indeed called in M-x gud-gdb
buffers.  So does M-x gdb buffers...  but in that case, gdb just seems
to ignore it, as it should.  So M-x gdb sets up gdb in a way that
gud-gdb doesn't.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #92 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Thu, 24 Sep 2020 17:16:54 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: dima <at> secretsauce.net,  21777 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org
> Date: Wed, 23 Sep 2020 14:53:53 +0200
> 
> Andreas Schwab <schwab <at> linux-m68k.org> writes:
> 
> >> I'm not sure I agree: how is an unlimited setting different from any
> >> other setting?
> >
> > It is special, as it never matches any real terminal size.
> 
> Indeed.  If gdb has disabled the pager, then Emacs telling gdb about the
> changed size shouldn't enable the pager.

Such a change is already being considered for inclusion in GDB, see

  https://sourceware.org/pipermail/gdb-patches/2020-September/172031.html

Message #95 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Thu, 24 Sep 2020 16:29:06 +0200

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

> Such a change is already being considered for inclusion in GDB, see
>
>   https://sourceware.org/pipermail/gdb-patches/2020-September/172031.html

Great.

And I'm guessing that the pager doesn't get switched on in the M-x gdb
case because the communication is over a separate socket (-i=mi), and
gdb just ignores the notification in that case?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #98 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Thu, 24 Sep 2020 18:06:52 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: dima <at> secretsauce.net,  21777 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org
> Date: Thu, 24 Sep 2020 16:15:29 +0200
> 
> Anyway, set-process-window-size is indeed called in M-x gud-gdb
> buffers.  So does M-x gdb buffers...  but in that case, gdb just seems
> to ignore it, as it should.  So M-x gdb sets up gdb in a way that
> gud-gdb doesn't.

Yes, "M-x gdb" doesn't start Readline in GDB, and so GDB doesn't think
it runs with output to a terminal device.  "M-x gud-gdb", OTOH,
invokes GDB as an interactive program via PTY.

Message #101 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Thu, 24 Sep 2020 18:08:19 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: dima <at> secretsauce.net,  21777 <at> debbugs.gnu.org,  schwab <at> linux-m68k.org
> Date: Thu, 24 Sep 2020 16:29:06 +0200
> 
> And I'm guessing that the pager doesn't get switched on in the M-x gdb
> case because the communication is over a separate socket (-i=mi), and
> gdb just ignores the notification in that case?

In the -i=mi case, GDB doesn't behave as if its output is a terminal
device.

Message #104 received at 21777 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21777 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, dima <at> secretsauce.net
Subject: Re: bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful
 inside emacs
Date: Fri, 25 Sep 2020 11:55:22 +0200

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

> Yes, "M-x gdb" doesn't start Readline in GDB, and so GDB doesn't think
> it runs with output to a terminal device.  "M-x gud-gdb", OTOH,
> invokes GDB as an interactive program via PTY.

Yup.  Then I guess there's nothing here to be done on the Emacs side of
things, and I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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