From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: *scratch* buffer documentation
Date: Thu, 26 Dec 2019 12:00:53 +0900 [thread overview]
Message-ID: <D88DF0A4-06CC-4AC3-8ADC-AFDB452E526D@traduction-libre.org> (raw)
In-Reply-To: <VI1P194MB0429BB2EB7BBED60EFABD415962B0@VI1P194MB0429.EURP194.PROD.OUTLOOK.COM>
> On Dec 26, 2019, at 11:29, arthur miller <arthur.miller@live.com> 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 <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
Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune
next prev parent reply other threads:[~2019-12-26 3:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-24 23:58 *scratch* buffer documentation Jean-Christophe Helary
2019-12-25 1:24 ` Óscar Fuentes
2019-12-25 1:44 ` Jean-Christophe Helary
2019-12-25 14:55 ` Eli Zaretskii
2019-12-26 0:54 ` Jean-Christophe Helary
2019-12-26 2:29 ` arthur miller
2019-12-26 3:00 ` Jean-Christophe Helary [this message]
2019-12-26 3:27 ` Óscar Fuentes
2019-12-26 5:19 ` Jean-Christophe Helary
2019-12-26 5:20 ` Jean-Christophe Helary
2019-12-26 16:22 ` Eli Zaretskii
2019-12-26 17:15 ` Jean-Christophe Helary
2019-12-26 17:36 ` Lars Ingebrigtsen
2019-12-26 18:14 ` Jean-Christophe Helary
2019-12-26 20:25 ` Eli Zaretskii
2019-12-27 1:03 ` Jean-Christophe Helary
2019-12-27 8:12 ` Eli Zaretskii
2019-12-27 9:12 ` Jean-Christophe Helary
2019-12-27 9:26 ` Eli Zaretskii
2019-12-27 9:44 ` Jean-Christophe Helary
2019-12-27 11:31 ` VanL
2019-12-27 14:06 ` Eli Zaretskii
2019-12-27 18:24 ` John Yates
2019-12-27 18:45 ` Eli Zaretskii
2019-12-27 16:12 ` Drew Adams
2019-12-27 17:07 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D88DF0A4-06CC-4AC3-8ADC-AFDB452E526D@traduction-libre.org \
--to=jean.christophe.helary@traduction-libre.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.