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

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

dima@secretsauce.net
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



Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
Dima Kogan <[hidden email]> 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, [hidden email]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

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

dima@secretsauce.net
Andreas Schwab <[hidden email]> writes:

> Dima Kogan <[hidden email]> 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?



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Dima Kogan <[hidden email]>
> Date: Wed, 28 Oct 2015 15:57:37 -0700
> Cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

dima@secretsauce.net
Eli Zaretskii <[hidden email]> writes:

>> From: Dima Kogan <[hidden email]>
>>
>> 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.



Reply | Threaded
Open this post in threaded view
|

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

dima@secretsauce.net
Dima Kogan <[hidden email]> writes:

> Eli Zaretskii <[hidden email]> writes:
>
>>> From: Dima Kogan <[hidden email]>
>>>
>>> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by dima@secretsauce.net
> From: Dima Kogan <[hidden email]>
> Cc: [hidden email], [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by dima@secretsauce.net
> From: Dima Kogan <[hidden email]>
> Cc: [hidden email], [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

dima@secretsauce.net
Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Dima Kogan <[hidden email]>
> Cc: [hidden email], [hidden email]
> Date: Fri, 30 Oct 2015 02:13:02 -0700
>
> Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> Date: Fri, 30 Oct 2015 11:32:47 +0200
> From: Eli Zaretskii <[hidden email]>
> Cc: [hidden email], [hidden email]
>
> > - 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?



Reply | Threaded
Open this post in threaded view
|

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

dima@secretsauce.net
Eli Zaretskii <[hidden email]> writes:

>> Date: Fri, 30 Oct 2015 11:32:47 +0200
>> From: Eli Zaretskii <[hidden email]>
>> Cc: [hidden email], [hidden email]
>>
>> > - 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Dima Kogan <[hidden email]>
> Cc: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Stefan Kangas
In reply to this post by dima@secretsauce.net
Dima Kogan <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Cc: Dima Kogan <[hidden email]>,  [hidden email],
>   [hidden email]
> Date: Sun, 20 Sep 2020 23:18:32 +0200
>
> Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Eli Zaretskii <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> Date: Mon, 21 Sep 2020 16:07:06 +0200
>
> Eli Zaretskii <[hidden email]> 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?



Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
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, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Eli Zaretskii
> From: Lars Ingebrigtsen <[hidden email]>
> Cc: [hidden email],  [hidden email],  [hidden email]
> 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.



12