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]).