From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Some question about display-buffer action functions Date: Sun, 29 Jan 2012 19:44:01 +0100 Message-ID: References: <4F25829F.8000104@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1327862689 21461 80.91.229.3 (29 Jan 2012 18:44:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 29 Jan 2012 18:44:49 +0000 (UTC) Cc: Emacs developers To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 29 19:44:48 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 1RrZk7-0002yC-Vq for ged-emacs-devel@m.gmane.org; Sun, 29 Jan 2012 19:44:48 +0100 Original-Received: from localhost ([::1]:39890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrZk7-0004Eb-8F for ged-emacs-devel@m.gmane.org; Sun, 29 Jan 2012 13:44:47 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:45052) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrZk3-0004EG-ON for emacs-devel@gnu.org; Sun, 29 Jan 2012 13:44:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrZk2-000599-Hu for emacs-devel@gnu.org; Sun, 29 Jan 2012 13:44:43 -0500 Original-Received: from mail-pw0-f41.google.com ([209.85.160.41]:60321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrZk2-000591-8C for emacs-devel@gnu.org; Sun, 29 Jan 2012 13:44:42 -0500 Original-Received: by pbaa12 with SMTP id a12so3393438pba.0 for ; Sun, 29 Jan 2012 10:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=SyQJQ2cc0brATBUPiptVMLjfLAMbMgm1w7BNFo3VdeM=; b=CbR8CP9mu5Um429u8iIAgj5ECqxTlUkOxPPsAI/olvLJxLj9x2kWzoGcsZZT0sYAFE auc/IVQdXPp4bHrIA2Dm/yWvZ0B+lX8rxLFfPET+RdYGWtI++Ql4DNsD/tYbFZVq3Y4Y Vww6p+Bq29Hl3UK22gJNDU0sE74TFri2jnv4g= Original-Received: by 10.68.199.38 with SMTP id jh6mr34502220pbc.77.1327862681173; Sun, 29 Jan 2012 10:44:41 -0800 (PST) Original-Received: by 10.143.37.9 with HTTP; Sun, 29 Jan 2012 10:44:01 -0800 (PST) In-Reply-To: <4F25829F.8000104@gmx.at> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.160.41 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:148017 Archived-At: On Sun, Jan 29, 2012 at 18:32, martin rudalics wrote: > Basically that's what side windows should eventually do. =C2=A0In your ca= se > the INF window would be the bottom side window with slot number zero. > It's either reused or created and weakly dedicated so it's not reused by > other buffer display functions. As I said, weak dedication fails for the "(switch-to-buffer next nil t)" call in bs-cycle-next. I'd like a style of dedication that said "that window can only display a buffer from THIS list, and nothing else". > How is `my-create-inferior-buffer-and-window' different from > `jb-inferior' (apart from the missing ALIST argument)? =C2=A0Also, wouldn= 't > `pop-to-buffer' (indirectly, via `display-buffer-alist') call > `my-create-inferior-buffer-and-window' again? 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'm not sure I understand what you mean here: Shouldn't the setup of > _any_ buffer appearing in INF be under your control via `jb-setup'? 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.) > 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. > Neither of these hooks is appropriate here. Oh, I'm sure they could be beaten into submission; but I prefer not to follow that route. > It should be passed just the window after `set-window-buffer' since then > the buffer can be easily derived from the window. =C2=A0BTW `display-buff= er' > doesn't necessarily select the window. You're right. Twice. :-) > 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. > Calling (display-buffer-record-window 'window window buffer) from within > `jb-inferior' should do that. 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. 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. My setup is a bit complex; I'll try to isolate a test case and file a bug. > I'm by no means against a `display-buffer-hook'. Note that my preferred fix is not a hook variable, but a hook action. >=C2=A0But first I'd like to > know why `display-buffer-alist' together with the ALIST argument cannot > be used to do that without calling a hook function. =C2=A0That is, why ca= n't > you do something like > > (defun jb-inferior (buffer alist) > =C2=A0(let ((window (window-with-parameter 'inferior-only))) > =C2=A0 =C2=A0(if window > =C2=A0 =C2=A0 =C2=A0 =C2=A0(set-window-buffer window buffer) > =C2=A0 =C2=A0 =C2=A0(setq window (display-buffer-pop-up-window buffer ali= st))) > =C2=A0 =C2=A0(display-buffer-record-window 'window window buffer) > =C2=A0 =C2=A0(jb-setup window) > =C2=A0 =C2=A0window)) 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. 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) (>=3D (window-body-height w) 10)))', that's a completely generic AF, and it cannot depend on any setup function. So, as currently implemented, either AFs are generic, and any window setup is done post-facto via hooks or the like, or they are strongly coupled to the window they choose and generality is lost. Hope I made myself clear. Thanks for the effort in understanding my ramblings, =C2=A0 =C2=A0 Juanma