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

[Dima Kogan <dima@secretsauce.net>]

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.