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: Wed, 17 Nov 2010 09:00:36 +0100 Message-ID: <4CE38BA4.2090407@gmx.at> References: <87k4kjfldo.fsf@gmail.com> <877hgifv9d.fsf@gmail.com> <4CDD6BDC.4010305@gmx.at> <8739r6foz3.fsf@gmail.com> <4CDD82E2.9070906@gmx.at> <87y68ye66d.fsf@gmail.com> <4CDE4D27.4000306@gmx.at> <87tyjle80w.fsf@gmail.com> <4CDE9942.1010205@gmx.at> <87pqu9dz8b.fsf@gmail.com> <4CDEB6B3.4080504@gmx.at> <87k4kgm5k1.fsf_-_@gmail.com> <4CE031A6.8010403@gmx.at> <87d3q7mxpu.fsf@gmail.com> <4CE0E8A0.1090905@gmx.at> <878w0un5rh.fsf@gmail.com> <4CE138E0.8000907@gmx.at> <874obimw0d.fsf@gmail.com> <4CE1674F.7050902@gmx.at> <87zktal69o.fsf@gmail.com> <4CE2B7B2.1020008@gmx.at> <87vd3xkm3u.fsf@gmail.com> 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 1289980852 13061 80.91.229.12 (17 Nov 2010 08:00:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 17 Nov 2010 08:00:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?UTF-8?B?xaB0xJtww6FuIE7Em21lYw==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 17 09:00:48 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 1PIcwh-00014P-Ou for ged-emacs-devel@m.gmane.org; Wed, 17 Nov 2010 09:00:48 +0100 Original-Received: from localhost ([127.0.0.1]:51148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIcwg-0006Fj-UW for ged-emacs-devel@m.gmane.org; Wed, 17 Nov 2010 03:00:46 -0500 Original-Received: from [140.186.70.92] (port=55482 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PIcwc-0006Fe-6d for emacs-devel@gnu.org; Wed, 17 Nov 2010 03:00:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PIcwa-0005ax-IZ for emacs-devel@gnu.org; Wed, 17 Nov 2010 03:00:41 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:55158 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PIcwa-0005aC-3J for emacs-devel@gnu.org; Wed, 17 Nov 2010 03:00:40 -0500 Original-Received: (qmail invoked by alias); 17 Nov 2010 08:00:37 -0000 Original-Received: from 62-47-60-30.adsl.highway.telekom.at (EHLO [62.47.60.30]) [62.47.60.30] by mail.gmx.net (mp018) with SMTP; 17 Nov 2010 09:00:37 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18Ebs4AiA8EznZ0gCPobe2qD4nr7broffXGQRe/Pu 7HQwdNUHTvYVrj User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87vd3xkm3u.fsf@gmail.com> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.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:132770 Archived-At: >> The variable `even-window-sizes' applies if and only if (1) a window is >> reused for showing the new buffer, (2) the window and the selected >> window appear above each other, and (3) both windows are full-width. (I >> removed restriction (3) in window-pub.) `even-window-sizes' doesn't >> apply when a window is split because the trunk always splits a window >> into two equally sized halves. > > Now I'm confused even more: we're talking about window-pub here, what > does trunk have to do with it? There's no `even-window-sizes' in trunk > Emacs. I meant `even-window-heights'. I use an even-window-sizes specifier because it applies to the horizontal case as well. > Again, I don't understand -- I was complaining about the window-pub > behaviour, so what will I gain by edebugging the trunk Emacs' > `split-window-sensibly'? It would have permitted to deduce in which case the window-pub branch failed to mimic the behavior of the trunk. > Well, as I see it the threshold variables were primarily intended to > provide a simple way for _users_ to customize window splitting, and for > the simple behaviour I describe (i.e. "only split windows if they're at > least this wide or that high") I think their semantics is optimal, and I > still don't see any equivalent in the new system. I guess setting > `min-height' to (/ split-height-threshold 2) with ".*" as a fallback > rule in `display-buffer-regexps' and overriding it in more specific > rules when necessary is as close as it gets? Yes. >> Moreover, I now allow to split internal windows like a frame's root >> window too, so the new window can appear at an arbitrary side of the >> frame. In that case, talking about a `split-height-threshold' hardly >> makes sense. > > Um, I don't understand. AIUI you can only split a live window, and the > only internal window that can be live is the root window as the only > window on a frame, right? So what does "arbitrary side of the frame" > mean? When you have a single window, you can split it horizontally or > vertically, but that's about it. What am I missing? `split-window' can split an arbitrary window. My `display-buffer-regexps', for example, contains the entry (("ChangeLog.*") same-frame (reuse-buffer-window) (new-window (root . below)) (min-height . 6) (min-width . 60) (adjust-height . 8)) so I can run ediff in side-by-side windows and edit a ChangeLog within one and the same frame without disrupting the ediff setup. Or, you can make sure that your completions always appear in a window on the right of the frame by adding something like (("*Completions*") same-frame (reuse-buffer-window) (new-window (root . right))) to `display-buffer-names'. And, since I'm able to display a buffer on an arbitrary side of a window I can write (("*Choices*") same-frame (reuse-buffer-window) (new-window (selected . above))) and have ispell use `display-buffer' for the *Choices* buffer. This means that people who want to see the *Choices* buffer on a separate frame can do so by simply customizing `display-buffer-names'. martin