RE: *scratch* buffer documentation

[arthur miller <arthur.miller@live.com>]

[-- Attachment #1: Type: text/plain, Size: 4164 bytes --]

I Think that you are missing one important thing: users are generally not idiots. Despite what Apple might think about computer users.

I have also being using Emacs for more then 20 years and I have even never red the fine manual more then for the occasional lookups, and yet it was always clear to me how buffers behave. Nor have I ever lost anything in that venerable scratch buffer. Emacs does have its dark corners, but I don't think saving buffers or scratch buffers or even that plist from customize is one of them.

Skickat från min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Från: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
Datum: 2019-12-26 01:54 (GMT+01:00)
Till: emacs-devel <emacs-devel@gnu.org>
Ämne: Re: *scratch* buffer documentation



> On Dec 25, 2019, at 23:55, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> 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




[-- Attachment #2: Type: text/html, Size: 5519 bytes --]