From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: managing windows in two frames Date: Wed, 04 Sep 2013 13:16:03 -0500 Message-ID: <858uzcbggs.fsf@stephe-leake.org> References: <8561uiclrj.fsf@stephe-leake.org> <5225DB8D.6060709@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1378318581 1427 80.91.229.3 (4 Sep 2013 18:16:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Sep 2013 18:16:21 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 04 20:16:25 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VHHcu-0005Mp-Pi for ged-emacs-devel@m.gmane.org; Wed, 04 Sep 2013 20:16:25 +0200 Original-Received: from localhost ([::1]:54664 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHHcu-00054a-9b for ged-emacs-devel@m.gmane.org; Wed, 04 Sep 2013 14:16:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHHcl-00052W-Hh for emacs-devel@gnu.org; Wed, 04 Sep 2013 14:16:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHHcf-0003Kq-68 for emacs-devel@gnu.org; Wed, 04 Sep 2013 14:16:15 -0400 Original-Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:12139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHHcf-0003JU-26 for emacs-devel@gnu.org; Wed, 04 Sep 2013 14:16:09 -0400 X-Authority-Analysis: v=2.0 cv=fJG7LOme c=1 sm=0 a=90MK7lSzN9hCuM5ahEFLfw==:17 a=M2z5juievrMA:10 a=yJoioP6_5VwA:10 a=zcTG9qZzcMYA:10 a=o_R75loqY_IA:10 a=9i_RQKNPAAAA:8 a=KGjhK52YXX0A:10 a=Lzix9T0G-1kA:10 a=mDV3o1hIAAAA:8 a=mos8dquSAAAA:8 a=X02qDDlAAAAA:20 a=RqOAJGx8AAAA:8 a=tj2ypqdyAAAA:8 a=qzUgV7yceVgUqR56sGkA:9 a=ITgWvxbI53kA:10 a=Q9BberuImaQA:10 a=npxmlrrLa1wA:10 a=90MK7lSzN9hCuM5ahEFLfw==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 75.87.84.149 Original-Received: from [75.87.84.149] ([75.87.84.149:56778] helo=TAKVER) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id D5/24-27973-5E877225; Wed, 04 Sep 2013 18:16:05 +0000 In-Reply-To: <5225DB8D.6060709@gmx.at> (martin rudalics's message of "Tue, 03 Sep 2013 14:52:29 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 71.74.56.122 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163187 Archived-At: martin rudalics 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- 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