From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: display-buffer-alist simplifications Date: Mon, 08 Aug 2011 15:14:25 -0400 Message-ID: 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 X-Trace: dough.gmane.org 1312831896 20089 80.91.229.12 (8 Aug 2011 19:31:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 8 Aug 2011 19:31:36 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 08 21:31:32 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 1QqVXq-0008Oi-VX for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 21:31:27 +0200 Original-Received: from localhost ([::1]:53324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqVHZ-0006Vm-0T for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2011 15:14:37 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:47107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqVHW-0006Nj-0v for emacs-devel@gnu.org; Mon, 08 Aug 2011 15:14:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqVHU-00067n-Nh for emacs-devel@gnu.org; Mon, 08 Aug 2011 15:14:33 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:14749 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqVHU-00067D-IC for emacs-devel@gnu.org; Mon, 08 Aug 2011 15:14:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKo0QE5FxKeo/2dsb2JhbABDpyZ4gUABAQQBViMFCws0EhQYDSSIAL42hkcEn1WEMQ X-IronPort-AV: E=Sophos;i="4.67,338,1309752000"; d="scan'208";a="130103034" Original-Received: from 69-196-167-168.dsl.teksavvy.com (HELO ceviche.home) ([69.196.167.168]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 08 Aug 2011 15:14:25 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 9954F6610B; Mon, 8 Aug 2011 15:14:25 -0400 (EDT) In-Reply-To: <4E3FA875.6020905@gmx.at> (martin rudalics's message of "Mon, 08 Aug 2011 11:12:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:143029 Archived-At: >> We can mark special-display-function obsolete right now. > It was so a couple of weeks ago. Yes, and I asked you to remove the obsolete signs, but now I realize that the one for special-display-function should have stayed. >>>> 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. All I saw was requests to get back the Emacs-23 behavior (tho I don't really understand what was different there either). > Drew uses `special-display-popup-frame' without dedicating frames IIRC. I don't think so. > The only person insisting on the dedicated feature is you. > And you still didn't give me an answer why you need it. I did: so that kill-buffer, bury-buffer, switch-to-buffer, and friends "do the right thing" (i.e. prefer to delete or iconify the window, or use some other frame, rather than show me some unrelated buffer in the selected window). And also so that display-buffer doesn't reuse that window. >>> The emacs-devel thread is called >>> "[display-buffer] a way to make it behave as before?" >> I don't understand: this seems to be a discussion about your new code, >> not about special-display-popup-frame and its reuse-window behavior. >> As a matter of fact he's asking to recover the old behavior. > It's about the reuse-window behavior in general. The one of > `special-display-popup-frame' is a special case. Than I'm lost. Not sure if it matters, tho. >> So I think this time around we're in a better position. But we still >> have to take it for granted that the old settings will be with us for >> a long time. All we can do with them is mark them obsolete, provide >> similar replacement behavior in the new settings and only use the old >> settings by calling the old code which we might even want to move to >> lisp/obsolete a some point. > 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. >> In my paper design, the equivalent to the "default >> special-display-regexp behavior" (which is the one that includes the >> "forcefully reuse-window regardless of display-buffer-reuse-frames") >> would be implemented by the display-buffer-dedicated-frame, so (just as >> in the original special-display-regexp design) it would only apply to >> buffers which are configured to be displayed in dedicated frames. > And I'm still asking why frames must be dedicated. They don't. But based on the fact that `same-frame' and `same-window' params only appeared "recently" and that FUNCTION is only used by a minority of users, then the vast majority of users of special-display-regexps use it to get dedicated frames. Now maybe they don't really want dedicated frames, they just want some way to say that some special buffers should be displayed in some separate frame, but since Emacs-20 this has made those windows/frames dedicated (and it made the code reuse any existing window) without hearing too many complaints about it. So I think it's a useful feature which we will want to provide through something like display-buffer-dedicated-frame which users will be free to use or not. > 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). >> I iconify the window, I kill the buffer, I use a command which deletes >> the frame and (if it's the last window displaying that buffer) kills the >> displayed buffer, I use some other command that ends up calling >> kill-buffer or bury-buffer, ... > Fine. All these should work with the quit-restore window parameter. Oh, that's nice. > And as a plus you should get it right when you just reused a window > showing another buffer on the same frame. If any of these doesn't work > please complain. It'll take me a while to change my setup to avoid dedicating windows, so don't hold your breath, Stefan