[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: patch gud-gdb to respect other-frame-window?
From: |
Stephen Leake |
Subject: |
Re: patch gud-gdb to respect other-frame-window? |
Date: |
Mon, 30 Jul 2018 11:49:12 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt) |
martin rudalics <address@hidden> writes:
>> Never mind; I realized I can set 'display-buffer-overriding-action' to
>> 'display-buffer-same-window in my ~/.emacs; that overrides this code,
>> and still lets other-frame-window do its thing.
>
> Please don't.
>
> If 'other-frame-window' sets 'display-buffer-overriding-action'
> itself, then it should _not_ be overridden by the user.
It's not quite that simple.
The current design of 'other-frame-window' only defines the behavior
when the other-frame or other-window prefixes are invoked; the behavior
with no prefix is left to the default Emacs code, or to a user-provided
'display-buffer-overriding-action'.
I don't remember if that was a concious decision, but in retrospect it
looks like the right one.
In more detail, 'other-frame-window' pushes overriding values in front
of user-set values in 'display-buffer-overriding-action' when the
other-window and other-frame prefixes are invoked, and pops them off
when the command is done, leaving the user-set values intact.
> It's a simple statement that 'other-frame-window' thinks that it is
> always right in its decision and the user has to either take it or
> leave it.
Not quite; it is only right when the prefixes are invoked.
We could change 'other-frame-window' to set the no-prefix
'display-buffer-overriding-action' as well, but I think it is better to
leave that to the user; some might like the current Emacs default
behavior (I did, until I ran into this gud-gdb behavior).
--
-- Stephe
Re: patch gud-gdb to respect other-frame-window?, martin rudalics, 2018/07/30
Re: patch gud-gdb to respect other-frame-window?, Stefan Monnier, 2018/07/30