Re: managing windows in two frames

[Stephen Leake]

Stefan Monnier <address@hidden> writes:

>>> `display-buffer' decisions are currently not based on a prefix argument
>>> given.
>> Right; that's new. I find it very convenient.
>
> But it's fundamentally broken (the prefix arg is an argument to the
> command being run, and the relationship between the command being run
> and the call to `display-buffer' can be arbitrary).
> IOW it's perfectly fine for personal use but we can't use that in
> lisp/window.el.

Yes, that makes sense.

>>> Maybe we can reconcile your idea with Stefan's proposal to use
>>> special prefixes for `display-buffer'-based functions.
>> Searching the emacs-devel archives, I found:
>> http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00299.html
>> http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00481.html
>> That doesn't give a very concrete proposal; can provide a better link?
>
> Make C-x 5 a prefix key which sets display-buffer-overriding-action for
> the duration of the next command.

Ok; that makes sense as a user interface.

Do you have a hint about how to implement it? I've never seen code tied
to a prefix, but I'm happy to experiment.

> Of course, other such prefixes could be used, such as C-x 4.  

Right, that would be "other window" (C-x 4 f is
`find-file-other-window'), while C-x 5 is "other frame". 

> And as Martin mentions, we'd want one that can say "display in current
> window". That should be no harder to define than C-x 4 or C-x 5.

C-x 6 is available. But display-buffer is not used for displaying a
buffer in the current window now, so I think this cannot be handled by
the same mechanism. At least not without major changes.

> More generally you could define such a prefix key that lets you specify
> a particular window to use in the next command.

Right. Designing a UI to let users select a particular window is a
challenge. I may think about that later ...

-- 
-- Stephe