From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: lru-window, window--try-to-split-window, split-width-threshold Date: Fri, 22 Aug 2008 16:45:06 -0700 Message-ID: <000301c904b1$6bf7e360$0200a8c0@us.oracle.com> References: <001301c90470$cb24e1d0$0200a8c0@us.oracle.com> <48AEF125.4060506@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1219449609 11416 80.91.229.12 (23 Aug 2008 00:00:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Aug 2008 00:00:09 +0000 (UTC) Cc: 'Emacs Devel' To: "'martin rudalics'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 23 02:01:02 2008 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 1KWgYt-0001PL-W0 for ged-emacs-devel@m.gmane.org; Sat, 23 Aug 2008 02:01:00 +0200 Original-Received: from localhost ([127.0.0.1]:57560 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KWgXw-0000w7-F0 for ged-emacs-devel@m.gmane.org; Fri, 22 Aug 2008 20:00:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KWgXr-0000vP-3b for emacs-devel@gnu.org; Fri, 22 Aug 2008 19:59:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KWgXo-0000uS-P0 for emacs-devel@gnu.org; Fri, 22 Aug 2008 19:59:54 -0400 Original-Received: from [199.232.76.173] (port=47595 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KWgXo-0000uP-HA for emacs-devel@gnu.org; Fri, 22 Aug 2008 19:59:52 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]:11011) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KWgXn-0000yK-Vg for emacs-devel@gnu.org; Fri, 22 Aug 2008 19:59:52 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m7MNxhZE017031; Fri, 22 Aug 2008 18:59:43 -0500 Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m7MH3Cwe016497; Fri, 22 Aug 2008 17:59:42 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt356.oracle.com with ESMTP id 11658400771219448835; Fri, 22 Aug 2008 16:47:15 -0700 Original-Received: from dradamslap1 (/141.144.89.89) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 22 Aug 2008 16:47:14 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckEebkcargX59srTROrzthAJyZyyAAI8j3A In-Reply-To: <48AEF125.4060506@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:102847 Archived-At: > > `split-width-threshold' was apparently introduced > > recently. Depending on its value, the lru-window > > can now get split horizontally to display *Completions* > > during minibuffer input. > > > > I have code that changes the display of completions > > (columns, spacing etc.), depending on the width > > *Completions* will have when it is displayed. Before it > > is displayed, I obtain (window-width (get-lru-window)) and > > use that as the assumed window width. > > > > This is no longer adequate, however, because the effective > > width might be, say, half of that if the lru window gets > > split horizontally to display *Completions*. > > And I can't simply use half of that width systematically, > > because there might be no horizontal split, depending on > > `split-width-threshold'. I don't know a way to know ahead > > of time whether a horizontal split will occur (without > > reproducing all of the code/logic of > > `window--try-to-split-window' - checking for dedicated > > windows etc.). > > So you can't fill the buffer _after_ the splitting occurred? > Relying on someone else to always choose the LRU window is > not very clean in the first place. Right you are. I use code similar to that used in Emacs. The formatting is done inside `with-output-to-temp-buffer', which displays the buffer only at the end. > > I tried this: (window--try-to-split-window (get-lru-window)), > > figuring that I might as well split the lru-window myself, > > if it is going to be split, so that I can get its new width > > and use that. > > > > The problem with this is that once the split occurs the > > window that was split is apparently no longer the lru window, > > so *Completions* gets displayed by splitting yet another window. > > Are you sure? No. ;-) In fact, looking again at the `display-buffer' code, I see what the problem was: (setq window-to-use (or (window--try-to-split-window (get-largest-window frame-to-use t)) (window--try-to-split-window (get-lru-window frame-to-use t)))) I split the lru window, but then `display-buffer' split the largest window, so two were split. And that's not all. To determine which window `display-buffer' would use, I would in fact need to duplicate a good deal of the logic from `display-buffer'. So I took your suggestion and displayed *Completions* first. Thx.