[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Controlling which windows can be selected by display-buffer-pop-up-windo

From: Jarosław Rzeszótko
Subject: Controlling which windows can be selected by display-buffer-pop-up-window
Date: Sat, 21 Dec 2013 19:18:49 +0100


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.

Jarosław Rzeszótko

reply via email to

[Prev in Thread] Current Thread [Next in Thread]