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

[Eric Abrahamsen]

Kaushal Modi <address@hidden> writes:

> On Thu, Sep 21, 2017 at 3:58 PM Eric Abrahamsen <address@hidden> wrote:
>
>  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.
>
> Thanks for the feedback.. I have some more food for thought:
>
> Case 1: We move forward with this AND condition of buffer-offer-save and 
> write-contents-functions
>
> - Here one would need to set both buffer-offer-save and 
> write-contents-functions for emacs to offer saving non-file buffers.
>
> Case 2: We revert this change that adds sensitivity to 
> write-contents-functions 
>
> - Here one would need to set both buffer-offer-save and 
> save-some-buffers-default-predicate (can be set just locally in a buffer?) 
> for emacs to offer saving non-file buffers.
>
> So in both cases, we would need to set 2 variables to some non-nil value. Is 
> Case 1 then better than Case 2? In Case 2, we don't need to change any code 
> (except for reverting 9b980e2[1] and ee512e9[2]).

I'm still in favor of case 1. `save-some-buffers-default-predicate' is
not buffer-local, and thus shouldn't be used by a single package author
to specify that his/her buffers should be eligible for save. What if two
packages both tried to use it? Though `save-some-buffers' slightly
abuses it as a boolean, I think it's clear that this option should be
left to the user. Also, it's docstring suggests that it's there to
*stop* buffers from being offered for save.

`buffer-offer-save', however, is buffer-local, meaning no one will step
on anyone else's toes.