[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: managing windows in two frames
From: |
Stephen Leake |
Subject: |
Re: managing windows in two frames |
Date: |
Wed, 04 Sep 2013 13:16:03 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) |
martin rudalics <address@hidden> 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
- managing windows in two frames, Stephen Leake, 2013/09/03
- Re: managing windows in two frames, martin rudalics, 2013/09/03
- Re: managing windows in two frames,
Stephen Leake <=
- Re: managing windows in two frames, Stephen Leake, 2013/09/04
- Re: managing windows in two frames, Stefan Monnier, 2013/09/04
- Re: managing windows in two frames, Stephen Leake, 2013/09/04
- Re: managing windows in two frames, martin rudalics, 2013/09/06
- Re: managing windows in two frames, Stephen Leake, 2013/09/07
- Re: managing windows in two frames, martin rudalics, 2013/09/07
- Re: managing windows in two frames, Stephen Leake, 2013/09/07
- Re: managing windows in two frames, martin rudalics, 2013/09/08
- RE: managing windows in two frames, Drew Adams, 2013/09/04
- Re: managing windows in two frames, martin rudalics, 2013/09/06