[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: move write-contents-functions higher up in basic-save-buff
Re: Proposal: move write-contents-functions higher up in basic-save-buffer
Wed, 24 May 2017 07:09:07 +0800
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)
Eli Zaretskii <address@hidden> writes:
>> From: Eric Abrahamsen <address@hidden>
>> Date: Tue, 23 May 2017 15:19:11 +0800
>> Most special-mode buffers aren't visiting a file, and thus they miss out
>> on all the `do-auto-save' and `save-some-buffers' mechanisms. I'd guess
>> a fair number of packages that use special-mode *do* have some concept
>> of saving, or persisting data in some other way.
>> I think the `write-contents-functions' hook would be an ideal way of
>> solving this problem, except that the way `basic-save-buffer' is
>> written, it won't let you get that far without having a file name.
>> My proposal is to declare `write-contents-functions' as *explicitly* a
>> hook for buffers that don't have any file associated with them at all
>> (this would be in contrast to `write-file-functions'). Then we'd move it
>> up higher in the process: either earlier in `basic-save-buffer', or all
>> the way up to `save-buffer' -- that way `basic-save-buffer' could only
>> be for buffers that have a file.
> Did you investigate the alternative -- teach basic-save-buffer to save
> buffers that don't visit files? If that's possible, it should be
I thought that's what I was doing! If a buffer isn't visiting a file,
there's essentially no way to guess what "saving it" would mean. The
mode that created the buffer would need to provide a function that does
the saving. Then basic-save-buffer would need to be taught to call that
function, instead of insisting that the buffer have a file.
My original thought was to have a new buffer-local variable,
save-buffer-function, that points to this function. Then it occurred to
me that write-contents-functions seems like a good place to do this. Now
I'm not sure.