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

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Wed, 20 Sep 2017 10:14:12 -0700
>> 
>> > How about this as a solution? With this, you only need to set buffer-over-save.
>> >
>> > diff --git a/lisp/files.el b/lisp/files.el
>> > index 0c30d40c13..5c05e3168b 100644
>> > --- a/lisp/files.el
>> > +++ b/lisp/files.el
>> > @@ -5188,15 +5188,15 @@ save-some-buffers
>> >        (and (buffer-live-p buffer)
>> >     (buffer-modified-p buffer)
>> >                      (not (buffer-base-buffer buffer))
>> > -                    (not (eq (aref (buffer-name buffer) 0) ?\s))
>> >                      (or
>> >                       (buffer-file-name buffer)
>> >                       (and pred
>> >                            (progn
>> >                              (set-buffer buffer)
>> >                              (and buffer-offer-save (> (buffer-size) 0))))
>> > -                     (buffer-local-value
>> > -                      'write-contents-functions buffer))
>> > +                     (and buffer-offer-save
>> > +                          (buffer-local-value
>> > +                           'write-contents-functions buffer)))
>> >                      (or (not (functionp pred))
>> >                          (with-current-buffer buffer (funcall pred)))
>> >                      (if arg
>> >
>> > Stefan? Eli?
>> 
>> As far as I can see, that's a good solution. Let's see what they say.
>
> 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.

Eric