From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Some question about display-buffer action functions Date: Mon, 30 Jan 2012 11:21:49 +0100 Message-ID: <4F266F3D.6030105@gmx.at> References: <4F25829F.8000104@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1327918994 25447 80.91.229.3 (30 Jan 2012 10:23:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2012 10:23:14 +0000 (UTC) Cc: Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 30 11:23:13 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RroOG-0005BJ-SF for ged-emacs-devel@m.gmane.org; Mon, 30 Jan 2012 11:23:13 +0100 Original-Received: from localhost ([::1]:51299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RroOG-0005e0-AH for ged-emacs-devel@m.gmane.org; Mon, 30 Jan 2012 05:23:12 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:42861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RroO8-0005dg-I3 for emacs-devel@gnu.org; Mon, 30 Jan 2012 05:23:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RroO6-0005II-Ni for emacs-devel@gnu.org; Mon, 30 Jan 2012 05:23:04 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:57279) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RroO6-0005ID-ES for emacs-devel@gnu.org; Mon, 30 Jan 2012 05:23:02 -0500 Original-Received: (qmail invoked by alias); 30 Jan 2012 10:22:58 -0000 Original-Received: from 62-47-49-102.adsl.highway.telekom.at (EHLO [62.47.49.102]) [62.47.49.102] by mail.gmx.net (mp004) with SMTP; 30 Jan 2012 11:22:58 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+O4TceyXaOSYGgx4ttiwHq9phX5Kc95skrLePTqP QozWD2zkymiBJu In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.22 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:148034 Archived-At: > As I said, weak dedication fails for the "(switch-to-buffer next nil > t)" call in bs-cycle-next. I forgot that `switch-to-buffer' has ((eq (window-dedicated-p) t) Actually `bs-cycle-next' should use `pop-to-buffer-same-window'. I'm still convinced that calling `switch-to-buffer' from Elisp is harmful. OTOH I don't understand: You invoke bs from the INF window and get surprised that it wants to switch to another buffer there? But this is inherently what you asked it to do, so the problem is more general. > I'd like a style of dedication that said > "that window can only display a buffer from THIS list, and nothing > else". That's what side windows try to tackle (unless the user explicitly overrides it by interactively calling `switch-to-buffer' in such a window). Alternatively, one could make `set-window-dedicated-p' accept a list of names of buffers that may replace the one currently shown in the corresponding window. > In my example, jb-inferior is an AF, to be used from > display-buffer-alist. But my-create-inferior-buffer-and-window is not > an AF, it's a user command that I invoke through a keybinding to > create INF and display the inferior buffer. It relies on jb-inferior > being set up in display-buffer-alist. If jb-setup could be done via a > hook (or any other suitable method), > my-create-inferior-buffer-and-window wouldn't be required at all. I still don't understand why `jb-inferior' should not call `jb-setup'. After all there could be some setup specific to INF windows. > Please, forget INF/SUP. Suppose I do "M-x list-buffers", and I've > customized display-buffer-alist for the "*Buffer List*" buffer, using > only standard AFs (the ones supplied with Emacs right now). How do I, > additionally, run a setup function to modify the window chosen by the > display-buffer call in list-buffers? Currently, I have to use window > hooks, or wrap list-buffers in a custom user command, or advice it. > (In fact, I use lot of advices just to run fit-window-to-buffer, which > is another example of the same problem.) And I'm still not sure whether this should be done in a hook. The fact that we have to resort to a hook means the alist concept sucks. In particular, because the hook function would have to discriminate, probably based on the name of the window's buffer, how to proceed. >> Do you mean that jb-inferior cannot call `display-buffer-pop-up-window' >> or that it's clumsy to do that? > > I mean that I'm being forced to decide in jb-inferior things that do > not really concern jb-inferior. AFs should ideally be able to either > choose and return a window, or return nil and pass the work to the > rest of AFs according to the user setup. If the current design forces > me to write custom AFs that always find and return a window, by hook > or by crook, OK, I can do that, but that's working against the spirit > of the feature, IMHO. Agreed. >> What about people who want to accomplish the necessary functionality via >> the customization interface? > > Cannot answer that, as I try to avoid the customization interface as > much as possible. I think that it should be possible to set up most properties of the window used (like minimum or ideal size, fixed-sizeness, dedicatedness to name a few) via `display-buffer-alist'. > The code for quit-window does: > > ((and (not prev-buffer) > (memq (nth 1 quit-restore) '(window frame)) > (eq (nth 3 quit-restore) buffer) > ;; Delete WINDOW if possible. > (window--delete window nil kill)) > > which doesn't kill if there's a previous buffer. And the buffer must be still the same too. Maybe `quit-window' should always delete the window when it's dedicated. But maybe you should rather use C-x 0 to get rid of a window for sure ;-) > But even doing > > (let ((w (get-buffer-window buffer)) > (window-size-fixed nil)) > (display-buffer-record-window 'window w buffer) > (set-window-prev-buffers w nil) > (window-resize w (- my-inferior-window-max-height > (window-total-height w)))) > > when I set up the window, quit-window still does not kill it. That would be a bug. If I do (progn (display-buffer-record-window 'window nil (window-buffer)) (set-window-prev-buffers nil nil)) in an arbitrary window, `quit-window' deletes it if there are other windows around. > My setup is a bit complex; I'll try to isolate a test case and file a bug. Please do. >> I'm by no means against a `display-buffer-hook'. > > Note that my preferred fix is not a hook variable, but a hook action. What is a "hook action"? Do you mean that the function called should be specified via `display-buffer-alist'? >> (defun jb-inferior (buffer alist) >> (let ((window (window-with-parameter 'inferior-only))) >> (if window >> (set-window-buffer window buffer) >> (setq window (display-buffer-pop-up-window buffer alist))) >> (display-buffer-record-window 'window window buffer) >> (jb-setup window) >> window)) > > There are two reasons against that: > > 1) I'd prefer not to couple jb-inferior to > `display-buffer-pop-up-window'. As a principle, I don't think AFs > should call other AFs if possible. That's something for > display-buffer-alist and the other user-configurable options to > decide. I wouldn't be too strict about this. > 2) Because that makes jb-inferior depend on jb-setup, so any > generality is lost. Of course my jb-inferior example is anything but > generic (I said as much). But if I write a new AF > `display-buffer-choose-window-with-predicate', which understands > actions like `(predicate . (lambda (w) (>= (window-body-height w) > 10)))', that's a completely generic AF, and it cannot depend on any > setup function. Why would calling `jb-setup' mean that `jb-inferior' _depends_ on it? Would this mean that when I call `jb-setup' from `display-buffer-hook' displaying a buffer depends on `jb-setup'? So far I thought that `jb-setup' would only do some additional adjustments after a suitable window has been found. If it fails, the window is still around and returned. > So, as currently implemented, either AFs are generic, and any window What does "generic" stand for in this context? > setup is done post-facto via hooks or the like, or they are strongly > coupled to the window they choose and generality is lost. Do you mean that we should avoid here to invoke `jb-setup' twice - once directly in an AF like `jb-inferior' and once via a hook? But this should be addressed by the coder of `jb-inferior'. martin