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 19:12:45 +0100 Message-ID: <4F26DD9D.1080101@gmx.at> References: <4F25829F.8000104@gmx.at> <4F266F3D.6030105@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 1327947254 16021 80.91.229.3 (30 Jan 2012 18:14:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2012 18:14: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 19:14:12 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 1Rrvk3-0005sr-PY for ged-emacs-devel@m.gmane.org; Mon, 30 Jan 2012 19:14:12 +0100 Original-Received: from localhost ([::1]:60216 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rrvk3-0001cy-1q for ged-emacs-devel@m.gmane.org; Mon, 30 Jan 2012 13:14:11 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:33607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rrvjv-0001cQ-Kh for emacs-devel@gnu.org; Mon, 30 Jan 2012 13:14:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rrvjp-0007xD-Oj for emacs-devel@gnu.org; Mon, 30 Jan 2012 13:14:03 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:42389) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Rrvjp-0007wA-BN for emacs-devel@gnu.org; Mon, 30 Jan 2012 13:13:57 -0500 Original-Received: (qmail invoked by alias); 30 Jan 2012 18:13:54 -0000 Original-Received: from 62-47-55-78.adsl.highway.telekom.at (EHLO [62.47.55.78]) [62.47.55.78] by mail.gmx.net (mp070) with SMTP; 30 Jan 2012 19:13:54 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/LLzUfqQDLf2ezQo2iusmTQxj6FTHhtao/pUReGO T6W6NTou6zS0t8 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:148043 Archived-At: > In that particular case, I'm not complaining about what bs-cycle-next > does. If I invoke bs-cycle-next in INF, it's only by mistake (but a > frequent one, because I use b-c-n all the time). As it is a mistake > that annoys me, I make INF strongly dedicated to avoid it. I would > prefer to make it softly dedicated, but that does not work currently. Another possibility would be to give the window a `no-switch-to-buffer' dedicated value and have `switch-to-buffer' / `display-buffer' observe that. > I would have preferred > to write display-buffer-choose-window-with-parameter (an AF to choose > a window according to some window parameter, passed through the action > list), and then use that to implement my SUP/INF setup. Then, after > 24.1, I would surely suggest that d-b-c-w-w-p could be a worthy > addition to window.el. jb-inferior isn't ;-) Sounds reasonable. Maybe a `display-buffer-in-window-with-predicate' would cover this. >> And the buffer must be still the same too. Maybe `quit-window' should >> always delete the window if it's dedicated. > > That would work for me, but I'm not sure is the best answer. `bury-buffer' does it. > Well, yes. I don't do that, because I use a single keybinding () > that subsumes all this: If I'm in SUP and there's no INF, create INF. > If I'm in SUP and there's an INF, switch to INF; and if I'm in INF, > kill it, bury the buffer and get back to SUP. Of course the function > bound to does use delete-window (or, in fact, window--delete). Where do you call `quit-window' here? Or did you want to call it here? >> What is a "hook action"? Do you mean that the function called should be >> specified via `display-buffer-alist'? > > Yes. It would be easy to do that. We would only have to decide on a name. >> Why would calling `jb-setup' mean that `jb-inferior' _depends_ on it? > > Just that it makes harder to use jb-inferior for things other than SUP/INF. And I thought that `jb-setup' would be the more general function. >> 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'. > > That's what I'm trying to do in this discussion: find a way to run it > once, *after* the window is chosen and set-window-buffer called. In my > original message, I listed the ways I know to make that happen (hooks, > advices, a wrapper function, etc.). IIUC we have three reasonable ways to do it: (1) Put all the things we want (like desired window size, dedicatedness, ...) into `display-buffer-alist'. That's what my original idea was and it's downside is that it makes `display-buffer-alist' bloated - we would have to put all this into its documentation. (2) Provide some sort of a hook within `display-buffer-alist'. That's easy to document and allows to call a function only for buffers that want it. The downside of this is that a user has to replicate it for each and every alist entry since entries are not merged. (3) Provide a standard `display-buffer-functions' hook. This means that the function called there has to handle every possible detail based on the window and the buffer's name. > (Note that I already have implemented a strongly coupled > jb-inferior/jb-setup, so this is not about how to fix my .emacs; it's > about how to make AFs, and action lists, more useful and flexible.) Sure. But you would have to test the usability of this first. martin