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: lru-window, window--try-to-split-window, split-width-threshold Date: Fri, 22 Aug 2008 09:04:44 -0700 Message-ID: <001301c90470$cb24e1d0$0200a8c0@us.oracle.com> 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 1219421366 15013 80.91.229.12 (22 Aug 2008 16:09:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Aug 2008 16:09:26 +0000 (UTC) To: "'Emacs Devel'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 22 18:10:19 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 1KWZDI-0000Uo-84 for ged-emacs-devel@m.gmane.org; Fri, 22 Aug 2008 18:10:12 +0200 Original-Received: from localhost ([127.0.0.1]:54404 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KWZCK-00032P-Nn for ged-emacs-devel@m.gmane.org; Fri, 22 Aug 2008 12:09:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KWZ8N-0001Lo-LB for emacs-devel@gnu.org; Fri, 22 Aug 2008 12:05:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KWZ8M-0001L0-0y for emacs-devel@gnu.org; Fri, 22 Aug 2008 12:05:07 -0400 Original-Received: from [199.232.76.173] (port=50121 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KWZ8L-0001Ks-QD for emacs-devel@gnu.org; Fri, 22 Aug 2008 12:05:05 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:19911) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KWZ8L-0001Ef-97 for emacs-devel@gnu.org; Fri, 22 Aug 2008 12:05:05 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m7MG4qYT021543 for ; Fri, 22 Aug 2008 10:05:02 -0600 Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m7M9R1NK022482 for ; Fri, 22 Aug 2008 10:04:51 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt356.oracle.com with ESMTP id 11646996961219421082; Fri, 22 Aug 2008 09:04:42 -0700 Original-Received: from dradamslap1 (/141.144.89.89) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 22 Aug 2008 09:04:42 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckEcMrD/byo8sRST3G9ExpiiWhQtQ== 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:102831 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.). 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. If I have two full-frame-width windows (frame split vertically), the effect is that both windows get split when *Completions* is displayed (and then unsplit when *Completions* is finished). Any suggestions? What am I missing? Is there some way, say, after splitting the lru window myself, that I can make it (or the new one) the lru again, so that `display-buffer' will use it for *Completions*? IOW, is there a way to *set* the lru window? Any help is welcome.