From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: undo-kill-buffer Date: Tue, 24 Oct 2006 17:41:17 -0700 Message-ID: References: <200610240856.57965.amax@redsymbol.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1161737048 32751 80.91.229.2 (25 Oct 2006 00:44:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 25 Oct 2006 00:44:08 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 25 02:43:58 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GcWq7-0002mF-Vx for ged-emacs-devel@m.gmane.org; Wed, 25 Oct 2006 02:41:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GcWq7-00014y-AI for ged-emacs-devel@m.gmane.org; Tue, 24 Oct 2006 20:41:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GcWpl-00014l-CM for emacs-devel@gnu.org; Tue, 24 Oct 2006 20:41:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GcWpj-00014T-La for emacs-devel@gnu.org; Tue, 24 Oct 2006 20:41:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GcWpj-00014K-Gv for emacs-devel@gnu.org; Tue, 24 Oct 2006 20:41:27 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GcWpj-00010m-Dt for emacs-devel@gnu.org; Tue, 24 Oct 2006 20:41:27 -0400 Original-Received: from rgmsgw02.us.oracle.com (rgmsgw02.us.oracle.com [138.1.186.52]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id k9P0fO3D015179 for ; Tue, 24 Oct 2006 19:41:24 -0500 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-83-3.vpn.oracle.com [141.144.83.3]) by rgmsgw02.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with SMTP id k9P0fNnk007192 for ; Tue, 24 Oct 2006 18:41:24 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200610240856.57965.amax@redsymbol.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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:61138 Archived-At: Yes, i use C-x k . Mostly it happens when I am doing some development that happens to involve a large number of files. Often then I will try to kill buffers I'm no longer working with, just to help keep organized or other reasons. Sometimes I'll kill a buffer (file) in this way and a moment later realize that there is another change I need to make. I don't have an answer for your question, but you might want to consider using C-x 0 more and C-x k less, at least for buffers that you are unsure you might want to revisit. Having lots of buffers around (but not displayed) is not necessarily bothersome or a performance hit. It can be a bit bothersome if you don't have a good way of filtering them so that you see only the ones you're interested in as candidates to visit. I tend to have lots of buffers around, but I use a good tool to filter them as completion candidates to visit. There are several such buffer-management or buffer-switching tools available - check Emacs Wiki: http://www.emacswiki.org/cgi-bin/wiki/CategoryBufferSwitching. If you are talking about files, then I'm not sure I understand. You can always revisit a file, creating a new buffer for it. If the file is not in the current directory, you can get to it quickly using the minibuffer history (cycling or matching) or the recent files list. If you are talking about files that you modify without saving, then see above, about buffers. I suspect that if you are envisaging being able to undo buffer deletion among a potentially large number of previously visited files, the management problem of specifying the buffer whose killing you want to undo might be bigger than the management problem you tried to solve in the first place by cleaning out (killing) unneeded buffers.