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: Should killing a help or compile buffer also delete the window? Date: Mon, 25 Apr 2005 15:04:37 -0400 Message-ID: References: <87is2c7mnx.fsf@brockman.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1114455667 4300 80.91.229.2 (25 Apr 2005 19:01:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Apr 2005 19:01:07 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 25 21:01:04 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DQ8oZ-00057R-Jn for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2005 21:00:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQ8u8-0004QM-V2 for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2005 15:06:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DQ8tu-0004Pu-5h for emacs-devel@gnu.org; Mon, 25 Apr 2005 15:05:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DQ8tt-0004Pi-Jd for emacs-devel@gnu.org; Mon, 25 Apr 2005 15:05:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQ8tt-0004MD-HX for emacs-devel@gnu.org; Mon, 25 Apr 2005 15:05:45 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DQ8w6-0004BA-Kl for emacs-devel@gnu.org; Mon, 25 Apr 2005 15:08:02 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 333BE340018; Mon, 25 Apr 2005 15:04:42 -0400 (EDT) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id C2BD04AC242; Mon, 25 Apr 2005 15:04:37 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id A46F8E6C19; Mon, 25 Apr 2005 15:04:37 -0400 (EDT) Original-To: Daniel Brockman In-Reply-To: <87is2c7mnx.fsf@brockman.se> (Daniel Brockman's message of "Sun, 24 Apr 2005 07:45:38 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.837, requis 5, autolearn=not spam, AWL 0.06, BAYES_00 -4.90) X-MailScanner-From: monnier@iro.umontreal.ca 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:36384 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36384 > I realize that you can't expect Emacs to know when you are done with a > window unless you actually tell when. The obvious way to tell when is > to type `C-x 1' or `C-x 0', but this leaves the temporary buffer > lingering, which makes me nervous. The way Emacs is expected to deal with it, is via the notion of dedicated windows. When a window is created by display-buffer, it is sometimes marked as dedicated, so that if the buffer it displays is killed the window is deleted (and if it's the only window in the frame, the frame is also deleted). I think Emacs should be a bit more aggressive about marking windows dedicated. My locally hacked Emacs has changed it to *always* mark the window as dedicated. The problem with that is that you can't switch-to-buffer in a dedicated window, so I introduced the notion of "softly-dedicated" which basically says "this window was created to display buffer FOO and has never displayed anything else". I.e. it's a form of the `dedicated' flag which does not prevent switch-to-buffer: instead when doing switch-to-buffer the flag gets set back to nil to indicate that the wnidow is not dedicated any more. It works great in my environment, don't know about others's. Stefan