From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Reitter Newsgroups: gmane.emacs.devel Subject: Re: Should killing a help or compile buffer also delete the window? Date: Mon, 25 Apr 2005 14:41:15 +0100 Message-ID: <430878965e82cea502cf4fd802417e4a@gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1114436610 30894 80.91.229.2 (25 Apr 2005 13:43:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Apr 2005 13:43:30 +0000 (UTC) Cc: daniel@brockman.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 25 15:43:25 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DQ3qP-00069u-6G for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2005 15:41:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQ3vv-0006pB-U4 for ged-emacs-devel@m.gmane.org; Mon, 25 Apr 2005 09:47:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DQ3vk-0006om-Us for emacs-devel@gnu.org; Mon, 25 Apr 2005 09:47:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DQ3vi-0006nj-6c for emacs-devel@gnu.org; Mon, 25 Apr 2005 09:47:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQ3vi-0006Pk-1E for emacs-devel@gnu.org; Mon, 25 Apr 2005 09:47:18 -0400 Original-Received: from [64.233.184.203] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DQ3t4-0006JO-77 for emacs-devel@gnu.org; Mon, 25 Apr 2005 09:44:34 -0400 Original-Received: by wproxy.gmail.com with SMTP id 50so1532525wri for ; Mon, 25 Apr 2005 06:41:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:content-type:message-id:content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=DDJM5h2AI6q5GjSS7I9SxufrRdfWIb3Ts8GJkG5CPJJRlD9T7lAwAazbMkEAI8Fn0eAgg3paibWtm1SxWeAOrMiGsF+v/utSEz/xqTl/q/MZ08Jam9mXbAMcE+b5ePHIG4P1pLpEXSOAHyd4c6sI5zv2+0dQ/G0ep4ggCtIyWcQ= Original-Received: by 10.54.40.63 with SMTP id n63mr1927298wrn; Mon, 25 Apr 2005 06:41:08 -0700 (PDT) Original-Received: from ?129.215.37.193? ([129.215.37.193]) by mx.gmail.com with ESMTP id 64sm245780wra.2005.04.25.06.41.08; Mon, 25 Apr 2005 06:41:08 -0700 (PDT) Original-To: emacs-devel@gnu.org X-Mailer: Apple Mail (2.622) 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:36363 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36363 Daniel Brockman brockman.se> writes: > > I don't want to spend time on thinking about it because I think it > > is unlikely to get anywhere. > > To be honest, I'm growing less and less confident myself that it would > be the best default behavior. While many people would definitely find > it convenient, I suspect others would just be confused or annoyed. I have the same problem, yet I want the behavior that you suggested in most cases. Here's what we do in AquaMacs (an Emacs distro with UI customizations for the Mac). It's quite a hack considered that the solution is not generic, but lists specific buffer names that have their own behavior. However, we don't only close windows for killed buffers, but we also create new frames (and thus a new window) for many types of newly buffers. But we can only do so selectively, because a lot of modes open new windows with new buffers that are not supposed to go into a new frame (consider ispell). So this is the solution that I've arrived at after playing around a bit; but I don't consider it very universal. It's a difficult problem as it has been said before. === (setq one-buffer-one-frame t) (defun open-in-other-frame-p (buf default) (set 'bufname (if (eq (type-of buf) 'string) buf (buffer-name buf))) ;; i guess we should use ;; with special-display-regexps instead (if one-buffer-one-frame (if (string-match "[ ]*\\*.*\\*[ ]*" bufname) (if (or (equal "\*Messages\*" bufname) (equal "\*info\*" bufname) (equal "\*scratch\*" bufname) (equal "\*Help\*" bufname) (equal "\*Backtrace\*" bufname) (string-match "[ ]*\*Customize*" bufname) ) t nil) default) nil )) ;; only for certain special buffers (defadvice switch-to-buffer (around sw-force-other-frame (&rest args) activate) (if (open-in-other-frame-p (car args) nil) (apply #'switch-to-buffer-other-frame args) ad-do-it) ) ;; we'd like to open new frames for some stuff (defadvice find-file (around force-other-frame (&rest args) activate) (if one-buffer-one-frame (apply #'find-file-other-frame args) ad-do-it) ) ;; buffer selected from menu bar (but not from popup menu when doing C-mouse-1) (defadvice menu-bar-select-buffer (around select-buffer-force-other-frame (&rest args) activate) (interactive) (if one-buffer-one-frame (switch-to-buffer-other-frame last-command-event) ad-do-it) ) ;; delete window when buffer is killed (defadvice kill-buffer (around force-delete-frame (&rest args) activate) (setq last-sel-window (selected-window)) (if (and (open-in-other-frame-p (car args) t) (not (special-display-p (buffer-name))) (eq (window-buffer) (car args))) (list (condition-case nil ( list ad-do-it (delete-window last-sel-window) ) (error ;; if this is the last open frame, just make it invisible (make-frame-invisible (selected-frame) t) ) )) ;; else ; don't delete ad-do-it ) )