Re: [Emacs-diffs] emacs-26 ee512e9: Ignore buffers whose name begins with a space in save-some-buffers

[Eli Zaretskii <eliz@gnu.org>]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Thu, 21 Sep 2017 12:57:39 -0700
> 
> > Are there any upsides and downsides to consider wrt this solution?  If
> > so, what are they?
> 
> It isn't so much upsides and downsides, as being careful to add a single
> bit of functionality, without messing up present behavior and
> expectations for a highly-trafficked bit of code. I think we can agree:
> 
> 1. To leave the buffer name out of it (don't handle leading spaces
>    differently)
> 2. To require `buffer-offer-save' to be explicitly set non-nil in order
>    to to consider a non-file buffer for potential saving. I think
>    Kaushal's right that we should require both `buffer-offer-save' and
>    `write-contents-functions' to be non-nil
> 3. To leave the current behavior of the PRED argument unchanged
> 
> So I think Kaushal's solution is good: it won't change anything at all
> except to add a clause saying "when `buffer-offer-save' and
> `write-contents-functions' have been set non-nil, consider the buffer
> for saving". That's only going to happen when someone explicitly
> requests it.

Reusing buffer-offer-save for this purpose sounds a strange solution
for me.  That variable already says that Emacs should offer saving the
buffer, and now it will have to do double duty in a convoluted manner.
It sounds like we are making the problem harder, rather than simpler,
for modes to solve.

IOW, if we require buffer-offer-save to be non-nil, why do we need to
also require that write-contents-functions is non-nil?  There are 2
clauses in the condition we are talking about, both require
buffer-offer-save to be non-nil, and the only difference between them
seems to be the condition of buffer size being positive.  Is that what
write-contents-functions is about -- to allow saving "empty" buffers?