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: Tue, 8 Aug 2006 11:32:30 -0700 (PDT) Message-ID: <49220.128.165.123.18.1155061950.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> <48104.128.165.123.18.1154986690.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 1155061987 19695 80.91.229.2 (8 Aug 2006 18:33:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Aug 2006 18:33:07 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 08 20:33:03 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 1GAWNn-0002Ij-SO for ged-emacs-devel@m.gmane.org; Tue, 08 Aug 2006 20:32:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GAWNm-0001Os-CF for ged-emacs-devel@m.gmane.org; Tue, 08 Aug 2006 14:32:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GAWNa-0001OQ-Ce for emacs-devel@gnu.org; Tue, 08 Aug 2006 14:32:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GAWNY-0001NZ-3W for emacs-devel@gnu.org; Tue, 08 Aug 2006 14:32:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GAWNX-0001NP-L8 for emacs-devel@gnu.org; Tue, 08 Aug 2006 14:32:35 -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 1GAWS1-0007b9-P5; Tue, 08 Aug 2006 14:37:14 -0400 Original-Received: from mailrelay3.lanl.gov (mailrelay3.lanl.gov [128.165.4.104]) by mailwasher-b.lanl.gov (8.13.6/8.13.6/(ccn-5)) with ESMTP id k78IWUnr016681; Tue, 8 Aug 2006 12:32:30 -0600 Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay3.lanl.gov (8.13.6/8.13.6/(ccn-5)) with ESMTP id k78IWUp0004491; Tue, 8 Aug 2006 12:32:30 -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 k78IWUFs021076; Tue, 8 Aug 2006 12:32:30 -0600 Original-Received: (from apache@localhost) by webmail1.lanl.gov (8.12.11.20060308/8.12.11/Submit) id k78IWUXh021074; Tue, 8 Aug 2006 11:32:30 -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; Tue, 8 Aug 2006 11:32:30 -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:58183 Archived-At: > Is it completely unacceptable even if the file in question is > principally > "owned" by code anyway? > > Yes, I think so. If it is unlikely that users will edit the file by > hand, that means there is unlikely to be a buffer to reuse. But IF > there is a buffer to reuse, it means the user edited the file by hand. > When he does so, you should not save his changes without his ok! It means the user -visited- the file explicitly. He may or may not have been interested in changing it by hand. I don't know, however, if this distinction is important. > 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. > > It is better to go ahead not reusing the buffer than to signal an > error. Aha -- perhaps there's a good "compromise" here. What if REUSE is treated as nil if the extant buffer is modified and WRITE is non-nil? Since the file may be visited using the wrong literality, there is already no guarantee that REUSE "does anything", so it's not drastically different. There is still the problem of the user's unsaved changes clashing, but client code can always detect this eventuality if it's important, and it can happen anyway (the user could intend to C-x C-w another buffer into the file, or the literality condition could apply to a modified buffer, or...). It would be more consistent to categorically only reuse unmodified buffers -- but for just reading the file, it can make sense to see the user's changes (if any), and any program which wanted to avoid "unstable" file contents can just pass REUSE as nil anyway. The relevant section of the doc string would then read REUSE non-nil means to use an existing buffer if it is visiting FILE. (The value of `find-file-existing-other-name' affects this determination.) The buffer will only be re-used if its literal status (see `find-file-literally') corresponds to RAW. To avoid interacting with a user's unsaved changes, the buffer will be ignored if it is modified and WRITE is non-nil. Note that reusing a buffer may mean that the text on which BODY operates differs from the actual contents of FILE. Should I add a note that the user's buffer can become outdated as a result of failed or unattempted reuse of it? Davis -- 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.