Re: *scratch* buffer documentation

[Jean-Christophe Helary]

> On Dec 26, 2019, at 11:29, arthur miller <address@hidden> wrote:
> 
> I Think that you are missing one important thing: users are generally not 
> idiots.

It is not about being idiots or not. But about how self-contained should the 
documentation be.

If you show me the place in the documentation where the default behavior is 
described then I'll need to worry about why I did not find it.

> Emacs does have its dark corners, but I don't think saving buffers

Indeed, saving buffers is not an issue. It is killing buffers that is.

Jean-Christophe

> -------- Originalmeddelande --------
> Från: Jean-Christophe Helary <address@hidden> 
> Datum: 2019-12-26 01:54 (GMT+01:00)
> Till: emacs-devel <address@hidden> 
> Ämne: Re: *scratch* buffer documentation
> 
> 
> 
> > On Dec 25, 2019, at 23:55, Eli Zaretskii <address@hidden> wrote:
> > 
> >> From: Jean-Christophe Helary <address@hidden>
> >> Date: Wed, 25 Dec 2019 08:58:45 +0900
> >> 
> >> I am not seeing anything in the Emacs manual that says a modified 
> >> *scratch* buffer does not trigger a "buffer modified. Kill anyway ?" 
> >> message when quitting.
> > 
> > This is a standard Emacs behavior with any buffer that doesn't visit a
> > file, so I'm not sure why you expected to see anything special in this
> > case.
> 
> Interesting. I've used emacs on and off for more than 20 years, and much more 
> in the last few years, and I was never aware of that. I always thought it was 
> a property of the *scratch* buffer. I guess it's because I was mostly using 
> buffer from files or saving new buffers to files.
> 
> So, I just checked the documentation (emacs manual) and here is what I found:
> 
> 19 Using Multiple Buffers
> 
> → nothing about that default behavior
> 
> 19.1 Creating and Selecting Buffers
> 
> → nothing about that default behavior
> 
> 19.4 Killing Buffers
> 
> Buried at the bottom of the info about C-x k:
> 
> "If you ask to kill a file-visiting buffer that is modified, then you must 
> confirm with ‘yes’ before the buffer is killed."
> 
> If that is how/where the default behavior is specified, maybe it ought to be 
> in a more preeminent location.
> 
> also, on the same page:
> 
> " The command ‘M-x clean-buffer-list’ is a convenient way to purge them; it 
> kills all the unmodified buffers that you have not used for a long time."
> 
> which kind of suggests that modified buffers would not be killed and thus 
> contradict the above "default".
> 
> And that's it, as far as I can tell. No other part of the Buffer chapter give 
> relevant information about what would happen to modified/unmodified buffers 
> that are killed. Maybe the information is located some place else, but then 
> we need to worry about how that information about buffers would be discovered 
> there.
> 
> It seems to me that a default behavior should be very clearly defined very 
> early in the manual. Buffers are a huge part of Emacs (and a huge difference 
> with other text editors, that basically expect a user facing "buffer" to be 
> saved after modification) and user have a strong expectation that user 
> modified data is safe and warning will be issued when that data is at risks 
> (in most reasonable cases).
> 
> So, would it be possible to have a strong clarification about the default 
> behavior and ephemeral quality of the buffers in the opening paragraphs of 
> "19 Using Multiple Buffers" ? That would be tremendously helpful.
> 
> Or am I still missing something ?
> 
> JC
> 
> 
> >>> Isn't that manifestly implicit on the first line of *scratch* ? :
> >>> 
> >>> ;; This buffer is for text that is not saved
> >> 
> >> No, because it is possible to save the buffer to a file. Also, the value 
> >> of this text can be changed, so there is no guarantee that the user sees 
> >> it.
> > 
> > Let's clarify the "is not saved" part of the text that is in the
> > buffer, it's much more efficient than any documentation anywhere.
> > 
> > If that text is changed, whoever changes it is expected to know what
> > he or she is doing, so let's not argue about that use case.
> > 
> > Thanks.
> > 
> 
> Jean-Christophe Helary
> -----------------------------------------------
> http://mac4translators.blogspot.com @brandelune

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune