Re: buffer-offer-save variable bug?

[Cor Gest <cor@clsnet.nl>]

Some entity, AKA Xah Lee <xah@xahlee.org>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)


> eval this code:
>
> (defun new-empty-buffer ()
>   "Opens a new empty buffer."
>   (interactive)
>   (let ((buf (generate-new-buffer "untitled")))
>     (switch-to-buffer buf)
>     (funcall (and initial-major-mode))
>     (setq buffer-offer-save t)))
>
> then call it. You'll have a new buffer. Now type something in it. Now,
> go to the menu “File‣Close”.
>
> You'll see that emacs closes the buffer immediately without offering
> save.

That is the corect behaviour of buffers.

Close means merely 'close'.
 AKA get this buffer-namespace outta-my-face;
 =OR=
 Icanhaz some fun answering basic questions in the article-buffer
 called 'gnu.emacs.help'.

list-all-buffers wil show you that "untiteled" still exists
in the namespace 'buffers' where all buffer-names exist.

If you do a 'kill-current-buffer' (C-x k) it will politely inform you with : 
"buffer has changed , kill it anyway ?   yes or no ?"

IF you DID_NOT change it by typing any drivel in it after creation 
then it will remove the buffer-name-space from the memory, but if you
activated auto-save and waited long enough (1 ... xxx seconds) you still 
can get it back from the auto-save-list with minimal (or even non) loss of data.

If you want to SAVE the buffer_content, you must ASK to write
the buffer to disk, and it will ask for a name when a file allready
exists with that buffer-name called 'untitled' or replace it, if asked.

In short, 'Close' is a non-destructive call in the buffer realm.

Some study of the emacs-lisp-buffer-behaviour should be a more 
usefull timewaster for you.



Cor

-- 
	Mijn Tools zijn zo modern dat ze allemaal eindigen op 'saurus'
        (defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
	     SPAM DELENDA EST       http://www.clsnet.nl/mail.php
                 1st Law of surviving a gunfight : Have a gun