Re: managing windows in two frames

[Stephen Leake <stephen_leake@stephe-leake.org>]

martin rudalics <rudalics@gmx.at> writes:

>> (defun display-buffer-reuse-frame (buffer alist)
>
> I'd call it `display-buffer-other-frame' ("reuse" currently has the
> connotation that a window already displays the buffer in question).

Ah; I was focused on "don't create a frame", similar to
`display-buffer-reuse-window' doesn't create a window. But you are
correct about it implying the buffer is already shown in that frame.

>>   "Display BUFFER in an existing frame other than the current frame.
>> If successful, return the window used; otherwise return nil.
>>
>> If ALIST has a non-nil `inhibit-switch-frame' entry, avoid
>> raising the frame.
>>
>> If ALIST has a non-nil `pop-up-frame-parameters' entry, the
>> corresponding value is an alist of frame parameters to give the
>> new frame."
>>   (let* ((frame (car (filtered-frame-list
>
> This is overly restrictive.  

I'm not clear what you would relax. We don't want the current frame, and
we want a frame with an available window.

I guess we could allow creating a new window in an existing frame? So
far I have not encountered a case where that is needed.

>> 		      (lambda (frame)
>> 			(and
>> 			 (not (eq frame (selected-frame)))
>> 			 (not (window-dedicated-p
>> 			       (or
>> 				(get-lru-window frame)
>> 				(frame-first-window frame)))))))))
>
> The lru and first window of that frame could denote the same window.

Yes, in which case we might miss an available window.

> Here too we can add a new alist element for picking the window.

Yes, I did not try to add new 'get a window from a frame' functions, but
that could be useful here.

In practice, this has not yet done the wrong thing for me.

>> 	 (window
>> 	  (and frame
>> 	       (or
>> 		(get-lru-window frame)
>> 		;; lru-window can be nil if window was deleted, by ediff for example
>
> Can you give a scenario?  `get-lru-window' doesn't consider/return
> deleted windows IIRC.  It can return nil if all windows are dedicated or
> slelected.

When I started on this, it would fail after I ran and quit ediff, so I
blamed it on deleted windows. But I have not tried to reproduce that
problem in Emacs 24.3.

>> 		(frame-first-window frame-2))))
>
> What is frame-2 ?

Hmm. A bug; it should be 'frame'. It's left over from an earlier version
of the code. Since I didn't notice the bug, this demonstrates that
get-lru-window doesn't return nil currently.

> `display-buffer' decisions are currently not based on a prefix argument
> given.  

Right; that's new. I find it very convenient.

> 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?

If it is as simple as C-u C-u, it would work for me.

So far, I have not found a conflict between using C-u for window/frame
choice and other uses, but there probably are some.

In general, having only one prefix command (really two, since C-u C-u is
different from C-u, as is C-u C-u C-u for that matter) is restrictive.

>> The use case for these:
>>
>> I use two Emacs frames, side by side, filling the screen. This allows
>> two things:
>>
>> 1) opening other applications next to an Emacs frame
>
> If Emacs fills the screen there doesn't seem much space left for other
> applications ;-)

That is the point of the two frames; when I need to see another
application, I still want half a screen of Emacs. If Emacs was one
frame, it would hide the other application when I switch back to it, or
I'd have to resize the frame, which would squeeze all the windows.

Half a screen is better than squeezed windows.

>> 2) navigating between frames for horizontal movement (using window
>> manager keys), and between windows for vertical movement (using Emacs
>> keys).
>
> I'm using M-S-left, M-S-up ... to navigate to the window in that
> direction.

Bound to windmove-*, I assume. Someone else pointed those out privately;
I had not been aware of them. That does solve this part of my use case.

Although I've already bound all the M-S-C-<arrow> keys; it would be a
big change to switch to that now :).

>> `display-buffer-other-window-or-frame' gives the user flexible control
>> of all buffer display functions, via the prefix arg.
>
> We have to decide how to integrate pefix arguments in buffer display
> functions.  

Yes.

> So far, I don't know of a proposal that allows, for example,
> to use the "same" window, thus overriding an application that wants to
> display the buffer in another window.

Good point; I have not considered trying to implement that. There are
times when it is annoying to have a command use another window.
Especially now that I'm used to using my prefix commands for most
window/frame management. 

In the long run, I would hope that the user interface for choosing
another window/frame is easy enough to use that no application would
decide to use another window or frame, always leaving it up to the user.

-- 
-- Stephe