unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: undo-kill-buffer
Date: Tue, 24 Oct 2006 17:41:17 -0700	[thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMIECFCMAA.drew.adams@oracle.com> (raw)
In-Reply-To: <200610240856.57965.amax@redsymbol.net>

    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.

      parent reply	other threads:[~2006-10-25  0:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-24 15:56 undo-kill-buffer Aaron Maxwell
2006-10-24 16:11 ` undo-kill-buffer Stuart D. Herring
2006-10-24 16:46   ` undo-kill-buffer Aaron Maxwell
2006-10-24 16:36 ` undo-kill-buffer Andreas Schwab
2006-10-24 23:43 ` undo-kill-buffer Miles Bader
2006-10-24 23:51   ` undo-kill-buffer Aaron Maxwell
2006-10-25  0:14     ` undo-kill-buffer Stefan Monnier
2006-10-25  0:22       ` undo-kill-buffer Aaron Maxwell
2006-10-25  0:32         ` undo-kill-buffer Stefan Monnier
2006-10-25 14:37         ` undo-kill-buffer Stuart D. Herring
2006-10-25 16:05           ` undo-kill-buffer Drew Adams
2006-10-25 22:43           ` undo-kill-buffer Miles Bader
2006-10-25 23:02             ` undo-kill-buffer Edward O'Connor
2006-10-25 23:50               ` undo-kill-buffer Miles Bader
2006-10-26  8:53                 ` undo-kill-buffer Richard Stallman
2006-10-25 23:17             ` undo-kill-buffer David Kastrup
2006-10-25 23:46               ` undo-kill-buffer Miles Bader
2006-10-25  0:36       ` undo-kill-buffer Miles Bader
2006-10-25  0:24     ` undo-kill-buffer Miles Bader
2006-10-25  1:11       ` undo-kill-buffer Aaron Maxwell
2006-10-25  0:41 ` Drew Adams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EIENLHALHGIMHGDOLMIMIECFCMAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).