[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8615: Please make sure v q removes the buffer for JPGs just likeit d

From: Drew Adams
Subject: bug#8615: Please make sure v q removes the buffer for JPGs just likeit does for other files
Date: Wed, 23 Nov 2011 12:55:43 -0800

> > because I like my Emacs to accumulate buffers.
> That's the main problem: some users like to accumulate buffers
> and some users don't like.  So there should be an option to disable
> accumulating by `q'.  One variant is remap such as you recommended in
> http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg01136.html
> Another variant is adding a defcustom such as `quit-window-kills'.
> It seems defcustom is more user-friendly.

Another distinction that it might help to make here is the kind of buffer and
its purpose.  I have no problem accumulating buffers, in general, but I have no
need to accumulate buffers that are essentially temporary and part of a dialog,
once that dialog is finished.

Emacs currently displays some buffers as part of a (non-modal) dialog, but there
is no real (operational, code-aware) notion of such a dialog, and generally no
way for the code to know that the displayed buffer is no longer needed after the
dialog is finished (if the code even knows when it is finished).  Such a buffer
is really only for temporary display, but it is not handled using any simple
construct such as `with-temp-buffer'.  (A user will know, of course, and one
approach could be to have two different keys, one that blows the buffer away and
another that holds onto it.)

If this rings a bell, fine.  If not, fuggeddabowdit - I'm not interested in
belaboring this; we've been through it before.

I agree that a reasonable start would be a user option, as Juri suggests (and
has been suggested before) - some way for a user to express a preference.  "I
like my Emacs to accumulate buffers" is fine as an expression of individual
preference, but not as a guide to Emacs design for everyone.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]