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-alist simplifications Date: Tue, 09 Aug 2011 14:55:58 +0200 Message-ID: <4E412E5E.6030204@gmx.at> References: <87mxgem09k.fsf@stupidchicken.com> <4E22AE2B.5040806@gmx.at> <4E248102.6080904@gmx.at> <4E380918.3060806@gmx.at> <4E397611.5020603@gmx.at> <4E3C13D4.9000707@gmx.at> <4E3D4592.40809@gmx.at> <4E3FA875.6020905@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1312898183 15734 80.91.229.12 (9 Aug 2011 13:56:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 9 Aug 2011 13:56:23 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 09 15:56:15 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 1Qqmmz-0006PP-RK for ged-emacs-devel@m.gmane.org; Tue, 09 Aug 2011 15:56:14 +0200 Original-Received: from localhost ([::1]:41468 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qqmmz-0000Py-Pg for ged-emacs-devel@m.gmane.org; Tue, 09 Aug 2011 09:56:13 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qqmmt-0000OU-Ts for emacs-devel@gnu.org; Tue, 09 Aug 2011 09:56:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qqmmp-0000lA-By for emacs-devel@gnu.org; Tue, 09 Aug 2011 09:56:07 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:37398) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Qqmmp-0000kn-0X for emacs-devel@gnu.org; Tue, 09 Aug 2011 09:56:03 -0400 Original-Received: (qmail invoked by alias); 09 Aug 2011 12:56:00 -0000 Original-Received: from 62-47-51-122.adsl.highway.telekom.at (EHLO [62.47.51.122]) [62.47.51.122] by mail.gmx.net (mp022) with SMTP; 09 Aug 2011 14:56:00 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18I9ixCv3EIfh6dYsuCNd5Ff4ed7vgvyXrX9hI055 vlV/ybkDeqofYb 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: Genre and OS details not recognized. X-Received-From: 213.165.64.22 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:143056 Archived-At: >>>>> I'm not sure why you're so concerned about this reuse-window behavior of >>>>> special-display-popup-frame. >>>> Because I had some very hard time here discussing this with a user who >>>> can't live with such behavior. >>> And yet he wants to use dedicated frames? Can you give some more >>> details, because that sounds pretty odd. >> That person can't use `special-display-popup-frame' because it doesn't >> work correctly on his system. > > Again, I don't know where in that thread he says that nor why. The author said > > The main reason I want to do all within the current frame is because > > Emacs doesn't raise a hidden frame. On cygwin (I use it in the office) > > and on Fedora 14 Linux (I use it in home), Emacs puts a newly created > > frame on the top of the screen, but it doesn't for a frame that exists > > but is hidden. > > > > As for Fedora 14, I use an external program called `wmctrl' to make > > `raise-frame' work, but it has no effect on cygwin. Cf. > > http://lists.gnu.org/archive/html/emacs-devel/2006-10/msg01117.html > All I saw was requests to get back the Emacs-23 behavior (tho I don't > really understand what was different there either). The difference was that I interpreted `pop-up-frames' non-nil as the user's agreement to reuse a window on another frame. The same interpretation is implicit whenever a user adds a buffer to `special-display-regexps' making `special-display-popup-frame' search all visible frames. >> Sure. But using the old code _as is_ is impossible if you want "to turn >> the NOT-THIS-WINDOW into a SPECIFIER/RULE argument which could then make >> same-window-* really obsolete". > > Maybe not absolutely "as is", but it should be possible to keep most of > the code unchanged, I think. For some value of "most". >> It's just as if you wanted to reperesent one of those users who want >> the old behavior back. What would happen in your setup if a frame >> were not dedicated? > > It all depends, but when your code recently failed to mark windows as > dedicated, I pretty quickly noticed it because I ended up accumulating > lots of frames showing the same buffer (often a buffer I didn't even > ask to see). IIUC, dedicated frames make sense in one and only one constellation: (1) `pop-up-frames' is nil. (2) Not all windows get a special frame. (3) You are in a special frame and a `display-buffer' for some other buffer than the one shown there happens. This is the only scenario I can think of that should cause troubles when the frame of (3) is not dedicated. But the buffer shown instead should be a buffer the user asked to see. So what you report above indicates the existence of a bug elsewhere. As soon as you have the time please look into this again and report such behavior. > It'll take me a while to change my setup to avoid dedicating windows, so > don't hold your breath, There's one thing that won't work for you: `bury-buffer' doesn't iconify the frame but deletes it. Iconification would need some extra work. martin