On Thu, Sep 21, 2017 at 3:58 PM Eric Abrahamsen <eric@ericabrahamsen.net>
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]).

[1]:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9b980e2691afa3a7a967011fc004d352750fe618
[2]:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-26&id=ee512e9a825a6dbdf438a432b75b7e18d9a983c7

-- 

Kaushal Modi