Re: Missing `with' macro?

[Stuart D. Herring]

>     If we use REUSE nil and WRITE t, then if the user has visited the file
>     (which could easily be a file for which WRITE t makes sense, e.g.
>     ~/.emacs.d/.whatever-package-rc) and has unsaved changes in it, those
> are
>     effectively lost because they may clash with the updated file.
>
> Maybe that is correct.  It would be as if some other unrelated program
> had altered the file.  If the person tries to save his buffer, Emacs
> will report that the file has changed.
>
> To use the user's existing buffer would save the user's own unsaved
> changes without asking.  That is completely unacceptable.

Is it completely unacceptable even if the file in question is principally
"owned" by code anyway?  I can't imagine that `with-file' would ever be
invoked on someone's source code unless it was a specialized tool that
would (via confirmation or so) verify the user's intent.

> I can see one other conceivable way to handle this case: to merge the
> changes that the program makes into the user's own buffer, imitating
> the example of CVS merging remote and local changes.  But that is not
> easy to do.

I see other possibilities:
1. (and REUSE WRITE (buffer-modified-p #<buffer extant-buffer>) (error
"Attempt to co-opt user's unsaved changes")) - that is, only allow REUSE
and WRITE on an unmodified buffer.
2. Go on modifying (because of WRITE) the buffer (because of REUSE), but
don't save the changes at the end, or else ask the user whether to save
them.

Either of these could be combined with a query beforehand:
"Lisp wants to modify foobar.c.  (S)ave your changes first or (r)evert the
buffer first?  (s or r)"
(Of course, C-g would also be a useful response.)

> Unless we implement such merging, I stand by what I said:
> WRITE = t requires REUSE = nil.

I'd really like to keep the option, but if we can't find a reasonable
solution I'll do that.

> Please show me the code you're talking about; it is the only way I can
> understand this.

OK, I've done my homework now.  The querying function is
`ask-user-about-supersession-threat'; it's called from lock_file() in
filelock.c, which uses get_truename_buffer() to find the buffer whose
modification time to examine.  This means that if an existing buffer
visiting the file is out of date, and get_truename_buffer() happens to
return it instead of the up-to-date buffer created by `with-file', the
supersession query will be raised.

I don't know what the correct approach is here (without rewriting
lock_file()): should I `flet' `ask-user-about-supersession-threat', or
what?

My current version of `with-file' does avoid losing the proper file name
by destroying its filename only after entering the `unwind-protect' that
restores it, and restoring it as the first unwind action.  (This was made
much simpler by the use of `find-file-noselect-1', as it reduced the
period of time during which the file name needed to be hidden.)

> Nothing bad happens.  Don't worry about this.

OK.  Worrying halted (and `buffer-read-only' let-bound).

Davis

PS - While investigating this, I discovered the variable `buffer_count' in
buffer.c: it seems to never be used by any code anywhere.  Is it obsolete?

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.