From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Missing `with' macro? Date: Mon, 07 Aug 2006 01:01:20 -0400 Message-ID: References: <7dbe73ed0607240317g1bcdd564g66d075f809bcb7b2@mail.gmail.com> <33776.128.165.123.18.1154052850.squirrel@webmail.lanl.gov> <21839.128.165.0.81.1154394370.squirrel@webmail.lanl.gov> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1154926989 28578 80.91.229.2 (7 Aug 2006 05:03:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 Aug 2006 05:03:09 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 07 07:03:06 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G9xGc-0005FP-5V for ged-emacs-devel@m.gmane.org; Mon, 07 Aug 2006 07:03:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G9xGb-0001aP-Pc for ged-emacs-devel@m.gmane.org; Mon, 07 Aug 2006 01:03:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G9xEx-0000cq-3O for emacs-devel@gnu.org; Mon, 07 Aug 2006 01:01:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G9xEw-0000c6-80 for emacs-devel@gnu.org; Mon, 07 Aug 2006 01:01:22 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G9xEv-0000bx-R7 for emacs-devel@gnu.org; Mon, 07 Aug 2006 01:01:21 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G9xJ5-0003B4-SF for emacs-devel@gnu.org; Mon, 07 Aug 2006 01:05:39 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1G9xEu-0005xM-Ia; Mon, 07 Aug 2006 01:01:20 -0400 Original-To: herring@lanl.gov In-reply-to: <21839.128.165.0.81.1154394370.squirrel@webmail.lanl.gov> (herring@lanl.gov) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58157 Archived-At: 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.