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

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

[Dima Kogan]

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

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

[Andreas Schwab]

Dima Kogan <dima@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Dima Kogan]

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

> Dima Kogan <dima@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?

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

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Date: Wed, 28 Oct 2015 15:57:37 -0700
> Cc: 21777@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.

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

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dima Kogan <dima@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.

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

[Dima Kogan]

Dima Kogan <dima@secretsauce.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Dima Kogan <dima@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.

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

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: schwab@linux-m68k.org, 21777@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.

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

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: schwab@linux-m68k.org, 21777@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.

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

[Dima Kogan]

Eli Zaretskii <eliz@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.

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

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: schwab@linux-m68k.org, 21777@debbugs.gnu.org
> Date: Fri, 30 Oct 2015 02:13:02 -0700
> 
> Eli Zaretskii <eliz@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.

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 <eliz@gnu.org>
> Cc: 21777@debbugs.gnu.org, schwab@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?

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

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 30 Oct 2015 11:32:47 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 21777@debbugs.gnu.org, schwab@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

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

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: 21777@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.

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

[Stefan Kangas]

Dima Kogan <dima@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

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dima Kogan <dima@secretsauce.net>,  21777@debbugs.gnu.org,
>   schwab@linux-m68k.org
> Date: Sun, 20 Sep 2020 23:18:32 +0200
> 
> Eli Zaretskii <eliz@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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dima@secretsauce.net,  21777@debbugs.gnu.org,  schwab@linux-m68k.org
> Date: Mon, 21 Sep 2020 16:07:06 +0200
> 
> Eli Zaretskii <eliz@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?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dima@secretsauce.net,  21777@debbugs.gnu.org,  schwab@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.

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

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  dima@secretsauce.net,
>   21777@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?

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

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: larsi@gnus.org,  dima@secretsauce.net,  21777@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.

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

[Andreas Schwab]

On Sep 22 2020, Eli Zaretskii wrote:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: larsi@gnus.org,  dima@secretsauce.net,  21777@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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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@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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dima@secretsauce.net,  21777@debbugs.gnu.org,  schwab@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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dima@secretsauce.net,  21777@debbugs.gnu.org,  schwab@linux-m68k.org
> Date: Wed, 23 Sep 2020 14:53:53 +0200
> 
> Andreas Schwab <schwab@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

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dima@secretsauce.net,  21777@debbugs.gnu.org,  schwab@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.

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dima@secretsauce.net,  21777@debbugs.gnu.org,  schwab@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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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