buffer-offer-save variable bug?

buffer-offer-save variable bug?

[Xah Lee]

there seems to be a bug on how the var buffer-offer-save behaves.
Accordig to its inline doc: “Non-nil in a buffer means always offer to
save buffer on exit.  Do so even if the buffer is not visiting a
file.” but it does not seem to behave that way. Possibly this is not
bug but due to my ignorance of other elisp detail...

To test this which seems like a bug to me, do this:

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.

  Xah
∑ http://xahlee.org/

☄


On Sep 24, 5:51 am, rustom <rustompm...@gmail.com> wrote:
> On Sep 24, 4:42 pm, Xah Lee <x...@xahlee.org> wrote:
>
> > I actually have the line
> > (setq buffer-offer-save t)
> > in my code for new-empty-buffer, but emacs still closes the buffer
> > without saving, seemingly contrary to its doc.
>
> Do you have it on a hook? Like so?
>
> (add-hook 'lisp-interaction-mode-hook (function (lambda () (setq
> buffer-offer-save t))))
>
> The above works for me -- asking to save the scratch buffer *if
> changed*
> Only problem is that fundamental-mode does not AFAIK have a hook.
> Wonder why...

Re: buffer-offer-save variable bug?

[Andreas Politz]

Xah Lee wrote:
> there seems to be a bug on how the var buffer-offer-save behaves.
> Accordig to its inline doc: “Non-nil in a buffer means always offer to
> save buffer on exit.  Do so even if the buffer is not visiting a
> file.” but it does not seem to behave that way. Possibly this is not
> bug but due to my ignorance of other elisp detail...
> 

I think 'on exit', in this case, stands for 'when exiting emacs'.

-ap

> To test this which seems like a bug to me, do this:
> ... 

Re: buffer-offer-save variable bug?

[Cor Gest]

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 

Re: buffer-offer-save variable bug?

[Nikolaj Schumacher]

Cor Gest <cor@clsnet.nl> wrote:

> 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.

Sorry if this is "basic" to you, but I didn't get a lot of what you're saying.

First of all, there is no `list-all-buffers', do you mean `list-buffers'?
And are you saying that after "closing" a buffer, it will still be there?

> 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 ?"

I think Xah's point was that it didn't, which I can confirm.  Is
something missing in the example?

> and it will ask for a name when a file allready exists with that
> buffer-name called 'untitled'

This sentence I really cannot parse...

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

Huh?  File->Close is an alias for kill-this-buffer.  If that isn't meant
to be destructive, I don't know what is...


regards,
Nikolaj Schumacher

Re: buffer-offer-save variable bug?

[Cor Gest]

Some entity, AKA Nikolaj Schumacher <me@nschum.de>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)


>> 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 ?"
>
> I think Xah's point was that it didn't, which I can confirm.  Is
> something missing in the example?

Anyone can screw-up by scribbling unsave code, which trashes data, 
can't they. ;-)

He shoud have included to run the hooks the hooks which
check before killing a buffer. 
Which is mentioned in the fine manual about 'kill-buffer'.

The scratch-buffer isn't protected like a 'normal' buffer anyway.

A well, the guy merely dislikes the name *scratch* and has a untitled
fetisch so why bother any further.


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 

Re: buffer-offer-save variable bug?

[Nikolaj Schumacher]

Cor Gest <cor@clsnet.nl> wrote:

> Some entity, AKA Nikolaj Schumacher <me@nschum.de>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
>
>>> 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 ?"
>>
>> I think Xah's point was that it didn't, which I can confirm.  Is
>> something missing in the example?
>
> Anyone can screw-up by scribbling unsave code, which trashes data, 
> can't they. ;-)
>
> He shoud have included to run the hooks the hooks which
> check before killing a buffer.

Yes, that was mentioned here, too.  But what you were said sounded like
there was something else to it.


regards,
Nikolaj Schumacher

PS: My emails to your address are bouncing.