emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing `with' macro?


From: Richard Stallman
Subject: Re: Missing `with' macro?
Date: Mon, 07 Aug 2006 01:01:20 -0400

    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.

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.

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

I don't follow this part:

    3. This does allow visiting a buffer repeatedly, but it doesn't entirely
    obviate the need for the kludge because the code that checks for a file
    being modified on disk since you read it when you try to edit it (my
    apologies that I don't know a name for this code)

I can't make sense of all those "it"s.

                                                      will notice another
    buffer visiting the file and will react if -its- modtime is out of date,
    even if the modtime of the edited buffer is recent.  I discovered this
    while testing; I should have mentioned it in comments.

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

    See (elisp)Intro to Buffer-Local; I was avoiding the problems discussed
    with the text "you can get Emacs very confused by binding the variable"
    near the bottom.  I realize now, re-reading that, that a `save-excursion'
    (or even just `save-current-buffer', I guess) can prevent problems here...
    but what happens if the buffer is killed before exiting the `let'?

Nothing bad happens.  Don't worry about this.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]