bug#12507: [debbugs-tracker] Processed: severity 12507 wishlist

[Drew Adams]

> > > What about improving write-region to use backup when needed?
> > > Possibly writing a new write-region-something function that
> > > handle backup, or a write-file-noselect function.
> > 
> > +1
> >
> > And please let us know how best to accomplish that (in the 
> > doc perhaps, but also in this thread).

Anyone?

> > It's not clear to me how to make a backup copy of a file 
> > without visiting that file in some buffer, however temporarily.

Stefan?  You were the one who pointed out why there was the change here to
`write-region' from `write-file'.  And you seemed to be suggesting that we
should still avoid `write-file' for that reason.

> > For example, I can imagine this as a way to append the 
> > region to a file and back it up:
> >
> >  (write-region (point-min) (point-max) FILE 'append)
> >  (with-current-buffer (find-file-noselect FILE) (backup-buffer))
>
> This is not efficient IMO,

No, of course not.  That's one reason I asked for a good way to do it.

My question for the example here was for the APPEND case of `write-region',
which has no equivalent wrt `write-file'.  But I certainly agree that if we're
going to visit the file anyway, then it is better to write to disk only once.
For that I have no problem with

(with-current-buffer (find-file-noselect FILE)
  ; erase if replacing, or leave in place if appending
  ; insert new (at end, if appending)
  (save-buffer))

> instead: 1) open FILE buffer 2) erase buffer
> 3) write data to it 4) save buffer.

Right.  Sounds good to me.  The question is open wrt visiting the file, however.

> > But IIUC `find-file-noselect' visits the buffer (and so 
> > "asks the user for confirmation if the file was modified
> > by some other process").  So that's apparently not the way
> > to go.  What is?
>
> What is the problem for this?

I was quoting Stefan.  He mentioned this problem as the reason for the 2005
change from the original `write-file' to the current `write-region'.  His point
was that we should avoid _visiting_ the file, for the reasons he gave.

My question is how to create a backup if you do not visit the file.

> What if you open another emacs session, bookmark something in this
> session, (don't save and don't quit session) switch to the initial
> session, bookmark something there and save bookmarks?
> It is good if it ask you for confirmation at some point, no?
> 
> > Leaving the question of visiting aside for the moment, what about
> > `backup-buffer' here?  Should it be `save-buffer' instead, 
> > so that the modes of FILE get updated properly?  Should it be just 
> > `basic-save-buffer-1' instead of `save-buffer'?
>
> `save-buffer' do all the job (saving and backing up), so why 
> writing to buffer and then using `backup-buffer'
> 
> > And should any such code take what Juri mentioned wrt vc 
> > into account?  If so, how?
>
> `save-buffer' handle that.

`save-buffer' means visiting the file first.  As do all of the other, more
partial, code combinations that might back up (`backup-buffer' etc.), AFAICT.

> > It's not clear to me how best to handle this
> > write-stuff-to-a-file-and-back-it-up-when-appropriate, but 
> > I (and perhaps others) would like to learn.  I haven't found
> > the answer by looking at the manuals or perusing the source
> > code.  Can you help?
> 
> I think that doing like in the patch I sent is not too bad:
> (with-current-buffer (find-file-noselect file)
>    write--data--here[...] (save-buffer))
> 
> No more is needed I think, but maybe I miss something?

You are missing Stefan's point about not visiting the file.

> Also, the use of `bookmark-version-control' is questionable, why
> handling this file specially?  If following that, we should have
> a special variable for .emacs-custom.el,
> desktop, history, etc... which is non--sense.

No, it's not nonsense.  Where I agree with you is that there can also be other
places, besides bookmarking, where you might want what `version-control' does
only in a blanket way to be done differently for specific files.

That was the aim, I assume, behind creating `bookmark-version-control' in the
first place.  It might be better to have a more general or central way to
specify this, rather than having additional user options for different files or
libraries.

(In Bookmark+, `bookmark-version-control' governs not only the bookmark file but
also two other bookmarking files: Bmenu state and user-generated command
definitions.)

One approach might be to generalize (or particularize, depending on your point
of view) `version-control', so that users can use it to also specify individual
behaviors for specific files or file-name regexp matches.

We could either modify `version-control' itself to get that effect or add a new
option like this to do it:

(defcustom version-control-overrides ()
  "Control the use of version numbers for backing up specific files.
Each entry is of the form (REGEXP-OR-VARIABLE . VALUE), where:
REGEXP-OR-VARIABLE is a regexp matching file names or the name of a
 file name-valued variable.
VALUE has the same meaning as the value of option `version-control,
 but affects only the files whose names match REGEXP."
  :type '(repeat (cons :tag "File & when"
                  (choice
                   (regexp   :tag "File-name regexp")
                   (variable :tag "File-name variable"))
                  (choice
                   (const :tag "Never"       never)
                   (const :tag "If existing" nil)
                   (other :tag "Always"      t))))
  :group 'backup :group 'vc)

The latter sounds better to me.  Then, to have specific control for your
bookmark file you would just add an entry like this: (bookmark-file . t).

(BTW, bug #12533 concerns the incorrect behavior of Customize for such a
defcustom.)

> If this variable is removed, the global value of 
> version-control will be used and .emacs.bmk will be backed
> up like any other file,

But that might not be what you want.  That's the point, presumably, of giving
you specific control for your bookmark file.  But I would be OK with removing
variable `bookmark-version-control' if a more general variable such as
`version-control-overrides' were added.

> like it does (or should do because it is broken with 
> write-region) with its default value 'nospecial.
> 
> Note that with the patch I sent, it seems a little bit faster to save,
> but maybe I am wrong, need to verify. (we write one time the data and
> save instead of writing two time and save)

See above.  Of course it is faster to write to disk only once.  The question
about visiting the file is still open, though.