From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stuart D. Herring" Newsgroups: gmane.emacs.devel Subject: Re: Missing `with' macro? Date: Mon, 7 Aug 2006 14:38:10 -0700 (PDT) Message-ID: <48104.128.165.123.18.1154986690.squirrel@webmail.lanl.gov> 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: herring@lanl.gov NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1154986939 29028 80.91.229.2 (7 Aug 2006 21:42:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 Aug 2006 21:42:19 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 07 23:42:18 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 1GACrQ-0007i0-Qw for ged-emacs-devel@m.gmane.org; Mon, 07 Aug 2006 23:42:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GACrQ-0002BS-CI for ged-emacs-devel@m.gmane.org; Mon, 07 Aug 2006 17:42:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GACnj-0000Eh-17 for emacs-devel@gnu.org; Mon, 07 Aug 2006 17:38:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GACni-0000Dm-0b for emacs-devel@gnu.org; Mon, 07 Aug 2006 17:38:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GACnh-0000Dc-PG for emacs-devel@gnu.org; Mon, 07 Aug 2006 17:38:17 -0400 Original-Received: from [192.65.95.54] (helo=mailwasher-b.lanl.gov) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GACrz-0004Mr-O7; Mon, 07 Aug 2006 17:42:44 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailwasher-b.lanl.gov (8.13.6/8.13.6/(ccn-5)) with ESMTP id k77LcBYw026106; Mon, 7 Aug 2006 15:38:11 -0600 Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay1.lanl.gov (8.13.6/8.13.6/(ccn-5)) with ESMTP id k77LcA1C027509; Mon, 7 Aug 2006 15:38:10 -0600 Original-Received: from webmail1.lanl.gov (localhost.localdomain [127.0.0.1]) by webmail1.lanl.gov (8.12.11.20060308/8.12.11) with ESMTP id k77LcA5T032672; Mon, 7 Aug 2006 15:38:10 -0600 Original-Received: (from apache@localhost) by webmail1.lanl.gov (8.12.11.20060308/8.12.11/Submit) id k77LcATe032667; Mon, 7 Aug 2006 14:38:10 -0700 X-Authentication-Warning: webmail1.lanl.gov: apache set sender to herring@lanl.gov using -f Original-Received: from 128.165.123.18 (SquirrelMail authenticated user 196434) by webmail.lanl.gov with HTTP; Mon, 7 Aug 2006 14:38:10 -0700 (PDT) In-Reply-To: Original-To: "Richard M. Stallman" User-Agent: SquirrelMail/1.4.6-7.el3.7lanl X-Priority: 3 (Normal) Importance: Normal X-PMX-Version: 4.7.1.128075 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:58165 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. 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 #) (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.