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: display-buffer cleverness - how to tame? Date: Tue, 05 May 2009 18:33:29 +0200 Message-ID: <4A006A59.1000406@gmx.at> References: <000c01c9cc8b$ba796c50$0200a8c0@us.oracle.com> <49FEA973.70705@gmx.at> <002a01c9ccc6$2221c840$0200a8c0@us.oracle.com> <49FF1AA0.9080601@gmx.at> <000e01c9ccdb$b0997180$c2b22382@us.oracle.com> <49FFE481.1070102@gmx.at> <004901c9cd8c$4d902e60$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1241541779 6505 80.91.229.12 (5 May 2009 16:42:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 May 2009 16:42:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 05 18:42:49 2009 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.50) id 1M1NjC-0003u0-J6 for ged-emacs-devel@m.gmane.org; Tue, 05 May 2009 18:42:46 +0200 Original-Received: from localhost ([127.0.0.1]:58321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1NjB-0006uD-TS for ged-emacs-devel@m.gmane.org; Tue, 05 May 2009 12:42:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1Nbs-0002vV-23 for emacs-devel@gnu.org; Tue, 05 May 2009 12:35:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1Nbn-0002sd-E0 for emacs-devel@gnu.org; Tue, 05 May 2009 12:35:11 -0400 Original-Received: from [199.232.76.173] (port=35096 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1Nbn-0002sX-A3 for emacs-devel@gnu.org; Tue, 05 May 2009 12:35:07 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:42046) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1M1Nbm-0004K5-Ka for emacs-devel@gnu.org; Tue, 05 May 2009 12:35:07 -0400 Original-Received: (qmail invoked by alias); 05 May 2009 16:35:03 -0000 Original-Received: from 62-47-62-89.adsl.highway.telekom.at (EHLO [62.47.62.89]) [62.47.62.89] by mail.gmx.net (mp026) with SMTP; 05 May 2009 18:35:03 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18IH7AzQv8I45JAARRc3h6QqQJqdEpBPmcaqXpu+2 fZmVB7Cv7cHmNO User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: <004901c9cd8c$4d902e60$0200a8c0@us.oracle.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:110681 Archived-At: > So the question is, then, how to get Emacs 23 to not split that (non-full-width > largest) window if it is not the lru window? Exact. > However, the doc string for `split-window-preferred-function' is not clear (to > me). First, this sentence is not grammatically correct; I can't understand it: > > "If non-nil, a function called with a window as single argument > supposed to split that window and return the new window." > > That seems to say that the window argument is supposed to split itself, or > something like that. Well, even an Emacs window won't split itself, but this part must be rewritten anyway. >>From your description above, the function decides, based on a window passed as > arg, which window to split, and then splits the window it chooses. Is that > correct? The function should split the window passed as arg but no one will ask whether it really split that window. As a matter of fact, the function may do anything it wants as long as it returns a live window. > Why is a particular window passed as arg, if the choice of which window to split > is up to the function? Because the standard (not user-written) functions will try to split the window passed as arg. > Is there some usual interpretation/use of that window > arg? The interpretation is "this is one of the windows Emacs 22 tried to split". > When `display-buffer' calls `split-window-preferred-function', which window > does it pass as arg? In a first call the largest window of the selected frame, in the second call the least recently used one. > What is the role/meaning of that window; how does > `display-buffer' pick it? You say the function is called "with the window to > split", but what does that mean, if it is the function itself that decides which > window to split (and splits it)? Up to Emacs 22 the identity of the window to split was hardcoded. The present code gives you a way to override that while keeping most of the historic details. I dislike the get-largest/LRU-window mumbo jumbo and rather have `split-window-preferred-function' decide which window(s) to split ... martin