From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-2?Q?Jaros=B3aw_Rzesz=F3tko?= Newsgroups: gmane.emacs.devel Subject: Controlling which windows can be selected by display-buffer-pop-up-window Date: Sat, 21 Dec 2013 19:18:49 +0100 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec520e8f51d81c504ee0f6d21 X-Trace: ger.gmane.org 1387651813 9031 80.91.229.3 (21 Dec 2013 18:50:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Dec 2013 18:50:13 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 21 19:50:20 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 1VuRcy-0006xw-0d for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 19:50:20 +0100 Original-Received: from localhost ([::1]:55213 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuRcx-0003Hm-LV for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 13:50:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuR8X-0005nd-Dw for emacs-devel@gnu.org; Sat, 21 Dec 2013 13:18:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuR8V-0006fu-3S for emacs-devel@gnu.org; Sat, 21 Dec 2013 13:18:53 -0500 Original-Received: from mail-pa0-x232.google.com ([2607:f8b0:400e:c03::232]:36247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuR8U-0006ff-Nv for emacs-devel@gnu.org; Sat, 21 Dec 2013 13:18:51 -0500 Original-Received: by mail-pa0-f50.google.com with SMTP id kp14so2020460pab.23 for ; Sat, 21 Dec 2013 10:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EQAvl9kGj3gM5XuSxYqL9oTAiSUey5/NyejqrYK2Jtk=; b=JhrZ5swwLlMrTz49t2ryHo/aMVAnIefoYHsvn+6cHkcDBToikUZZ973G6LSCPUNJMf sCJoiEQyZSpOO+0NoXyfBGcfFvAsIgW21t4Irj76eBC758lsndhjl0zyTf7U1mWnjMyg 7343BsoV2VrhSvr/w2x2QPI3Gg4lFZejf7TS69ipJIVqeQ/2AZFNdOIWa8r7cUuzjuJ2 2hlfc+RpeF813gPcBCh+bEgt6twO71XQD9Yxbt4w2Bm1DlnjB7Jd+1bqBunwI9EaOwT/ O9ndMgx3xPsJ74fpEHT0UOW4Uxpo0VBZyRK/vGOC56SJMg3M57+I+AvuDsuM1092aLUj hIRQ== X-Received: by 10.66.11.68 with SMTP id o4mr16291327pab.54.1387649929410; Sat, 21 Dec 2013 10:18:49 -0800 (PST) Original-Received: by 10.66.77.230 with HTTP; Sat, 21 Dec 2013 10:18:49 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::232 X-Mailman-Approved-At: Sat, 21 Dec 2013 13:50:17 -0500 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:166705 Archived-At: --bcaec520e8f51d81c504ee0f6d21 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hi, Is there any chance a more flexible mechanism for controlling which window is chosen to be split when a new buffer is about to displayed could make it into Emacs? I have been trying to implement a way to keep a toggleable terminal or compilation window at the bottom of an Emacs frame, that is only a few lines high and is never split or deleted unless the users requests it - I think this is a perfectly reasonable feature many people would like, and one present in many environments those days. Currently, to the extent I managed to learn, implementing a window that consistently keeps a fixed position and size and is never split, is possible only in two ways, one is a really dirty hack, and the second one requires reimplementing a lot of the mechanisms in window.el. What splits dedicated windows most frequently is a call to display-buffer-pop-up-window from display-buffer, and display-buffer-pop-up-window always uses either get-largest-window or get-lru-window as the window to split for displaying the new buffer, and it ignores whether the window is dedicated or not by passing t as the second argument to those functions. So, the only way to do this which would not require multiple days of effort is to basically break the get-largest-window and get-lru-window functions to always ignore dedicated windows, and I have only learnt of this after spending multiple hours in window.el and examining the ECB package, which does something like this: (defadvice get-largest-window (before xyz) (and (ad-get-arg 1) (ad-set-arg 1 nil))) (ad-activate 'get-largest-window) (defadvice get-lru-window (before xyz) (and (ad-get-arg 1) (ad-set-arg 1 nil))) (ad-activate 'get-lru-window) The only other existing path of implementing this I see is to add a new function to display-buffer-overriding-action, but then this function has to somehow reimplement all the default behaviour of Emacs just to exclude one window from being selected, because the behaviour of existing functions like display-buffer--maybe-pop-up-frame-or-window can not be changed by passing another argument or anything like this. I think another window parameter in addition to dedicated, like "persistent", and excluding windows with the parameter from all the default Emacs window-to-be-split selection functions would make the problem go away, and I don't see any disadvantages of this. I am of course willing to contribute a patch, if this sounds like a reasonable idea. Cheers, Jaros=B3aw Rzesz=F3tko --bcaec520e8f51d81c504ee0f6d21 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable
Hi,

Is there any chance a more flex= ible mechanism for controlling which window is chosen to be split when a ne= w buffer is about to displayed could make it into Emacs? I have been trying= to implement a way to keep a toggleable terminal or compilation window at = the bottom of an Emacs frame, that is only a few lines high and is never sp= lit or deleted unless the users requests it - I think this is a perfectly r= easonable feature many people would like, and one present in many environme= nts those days. Currently, to the extent I managed to learn, implementing a= window that consistently keeps a fixed position and size and is never spli= t, is possible only in two ways, one is a really dirty hack, and the second= one requires reimplementing a lot of the mechanisms in window.el.

What splits dedicated windows most frequently is a call to display-buff= er-pop-up-window from display-buffer, and display-buffer-pop-up-window alwa= ys uses either get-largest-window or get-lru-window as the window to split = for displaying the new buffer, and it ignores whether the window is dedicat= ed or not by passing t as the second argument to those functions. So, the o= nly way to do this which would not require multiple days of effort is to=A0= basically break the get-largest-window and get-lru-window functions to alw= ays ignore dedicated windows, and I have only learnt of this after spending= multiple hours in window.el and examining the ECB package, which does some= thing like this:

(defadvice get-largest-window (before xyz)
=A0=A0 (and (ad-get-arg 1= ) (ad-set-arg 1 nil)))
(ad-activate 'get-largest-window)
(defadvi= ce get-lru-window (before xyz)
=A0=A0 (and (ad-get-arg 1) (ad-set-arg 1 = nil)))
(ad-activate 'get-lru-window)

The only other existing= path of implementing this I see is to add a new function to display-buffer= -overriding-action, but then this function has to somehow reimplement all t= he default behaviour of Emacs just to exclude one window from being selecte= d, because the behaviour of existing functions like display-buffer--maybe-p= op-up-frame-or-window can not be changed by passing another argument or any= thing like this.

I think another window parameter in addition to dedicated, l= ike "persistent", and excluding windows with the parameter from a= ll the default Emacs window-to-be-split selection functions would make the = problem go away, and I don't see any disadvantages of this. I am of cou= rse willing to contribute a patch, if this sounds like a reasonable idea.
Cheers,
Jaros=B3aw Rzesz=F3tko
--bcaec520e8f51d81c504ee0f6d21--