emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

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