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: The window-pub branch Date: Thu, 18 Nov 2010 19:48:57 +0100 Message-ID: <4CE57519.7030403@gmx.at> References: 4CE031A6.8010403@gmx.at <4CE56872.6050502@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1290106160 26783 80.91.229.12 (18 Nov 2010 18:49:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 18 Nov 2010 18:49:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 18 19:49:13 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PJ9Xk-00009q-83 for ged-emacs-devel@m.gmane.org; Thu, 18 Nov 2010 19:49:12 +0100 Original-Received: from localhost ([127.0.0.1]:60244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PJ9Xj-0007hG-Nq for ged-emacs-devel@m.gmane.org; Thu, 18 Nov 2010 13:49:11 -0500 Original-Received: from [140.186.70.92] (port=41809 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PJ9Xe-0007gE-3s for emacs-devel@gnu.org; Thu, 18 Nov 2010 13:49:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PJ9Xc-0006dQ-43 for emacs-devel@gnu.org; Thu, 18 Nov 2010 13:49:06 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:44865 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PJ9Xb-0006bT-Ow for emacs-devel@gnu.org; Thu, 18 Nov 2010 13:49:04 -0500 Original-Received: (qmail invoked by alias); 18 Nov 2010 18:48:59 -0000 Original-Received: from 62-47-34-187.adsl.highway.telekom.at (EHLO [62.47.34.187]) [62.47.34.187] by mail.gmx.net (mp017) with SMTP; 18 Nov 2010 19:48:59 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19uBT5U9sduNdGrFBMA3tj0ZbSR9oQmMlR4pqR8Bg 5EfuaYGLNaNYZE User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <4CE56872.6050502@gmx.de> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:132823 Archived-At: > Is it possible to have display-buffer-function back? (Or same > functionality with new name if you prefer.) From the doc-string of `display-buffer-names': Any other symbol with a function definition means to call that function to display the buffer. The function is called with two arguments - the buffer to display and a list of specifiers - and is supposed to display the buffer and return the window used for that purpose. The function is also responsible for giving the variable `display-buffer-window' and the `quit-restore' parameter of the window used a meaningful value. So why do you think it's gone? You can define (defun display-buffer-in-other-window-on-same-frame (buffer specifiers) (display-buffer "*scratch*" '(same-frame (reuse-buffer-window . nil) (not-this-window . t)))) and put this into `display-buffer-names' or `display-buffer-regexps' or write (display-buffer "*scratch*" 'display-buffer-in-other-window-on-same-frame) > Also, is it possible to route any other functions that effect to > displaying a buffer (such as switch-to-buffer) through display-buffer > exclusively? With the exception of `switch-to-buffer' all these route now through `display-buffer'. I could add an option to have `switch-to-buffer' route through `display-buffer' as well. `set-window-buffer' can't be rewritten, for obvious reasons. > Also, is it possible to have same logic to "un-display" (hide) a > buffer, such that delete-buffer and bury-buffer are routed through > that, also exclusively? And then to have a hook too, such as > "hide-buffer-function"? Hiding a buffer is done by `replace-buffer-in-windows' which is called by `kill-buffer' (I suppose you mean that by "delete-buffer"). I don't understand the semantics of `bury-buffer' well enough. What would you want to put on that hook? > And yes, that would be to bypass all the interesting logic you just > designed and to replace it with something completely different. ;) IIUC only your first issue fits into this remark. The routing issue you raised goes into the opposite direction, I presume. And the "hiding" logic was redesigned (confer `switch-to-prev-buffer') but it's only loosely connected to buffer display proper. martin