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] a way to make it behave as before? Date: Wed, 22 Jun 2011 09:20:19 +0200 Message-ID: <4E0197B3.1080509@gmx.at> References: <4DFB7705.2000401@gmx.at> <4DFF1223.5030100@gmx.at> <4DFF3BA8.3070007@gmx.at> <4E00C2C8.6040303@gmx.at> 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: dough.gmane.org 1308727245 5335 80.91.229.12 (22 Jun 2011 07:20:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 22 Jun 2011 07:20:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Katsumi Yamaoka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 22 09:20:40 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QZHjs-0007bU-MP for ged-emacs-devel@m.gmane.org; Wed, 22 Jun 2011 09:20:40 +0200 Original-Received: from localhost ([::1]:46671 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZHjo-00031Q-R1 for ged-emacs-devel@m.gmane.org; Wed, 22 Jun 2011 03:20:36 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:42243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZHjb-00031K-Ax for emacs-devel@gnu.org; Wed, 22 Jun 2011 03:20:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZHja-0007es-AC for emacs-devel@gnu.org; Wed, 22 Jun 2011 03:20:23 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:35913) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QZHjZ-0007em-Vk for emacs-devel@gnu.org; Wed, 22 Jun 2011 03:20:22 -0400 Original-Received: (qmail invoked by alias); 22 Jun 2011 07:20:20 -0000 Original-Received: from 62-47-62-154.adsl.highway.telekom.at (EHLO [62.47.62.154]) [62.47.62.154] by mail.gmx.net (mp003) with SMTP; 22 Jun 2011 09:20:20 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19wtO5BI5pwDE7Kh7pUngnj4lDTYaZnCCzYwujqTC zjwRhCuuM1hxaS User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 213.165.64.23 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140828 Archived-At: >> Currently, I >> can reproduce the "display on another frame" behavior iff I make the >> selected window small enough and all other windows on this frame >> unusable. Please try once more. > > What does `unusable' mean? Dedicated. Maybe there are other means, but that's what I tried. >> If I prepend a (reuse-window nil nil nil) specifier to the first entry >> in `display-buffer-alist' the selected window gets reused (with the old >> unsplittable frame behavior). > > Verified. It's not what I want, though. I only want `C-x 4 f' > to split the current window or to use the other window within > the frame as exactly the same as old Emacsen do. I see. But does the current default now do what you need in this respect? Or are there additional glitches I shall repair? > That the new `display-buffer' and friends are useful is beyond > doubt, but I can imagine people will be getting flustered for > the new behavior sooner or later. For instance, someone in Japan > asked for a help last night; a frame that BBDB makes is too large, > a frame used to compose a mail is too small, etc. We can't support > all of them, can we? So, you'd better make `display-buffer-alist' > default to `conservative' or provide a switch that enables a user > to make `display-buffer' behave as before completely, I think. I fully agree with you. Your comments in this regard are highly appreciated. The problem is that I started to think about backward compatibility only about two weeks ago - till then I was debugging the `display-buffer-alist' based code. So most bugs of the past week were introduced in the phase when I wrote the backward compatibility layer (mostly what's done in the function `display-buffer-normalize-options'). > BTW, shouldn't the default size of a newly created frame follow > that of `emacs -Q' or `C-x 5 2' ? I feel 80x24 is too small. You're right. I removed that entry completely so it now uses the default value used by C-x 5 2. When, and if, you have the time to go through the default settings of `display-buffer-alist' once more and find anything that in your opinion just could lead to troubles please tell me. Thanks, martin