bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: 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@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]