From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: [dooglus@gmail.com: display problem after renaming open image files] Date: Tue, 03 Apr 2007 10:12:47 +0200 Message-ID: <868xd998qo.fsf@lola.quinscape.zz> References: <87ircfu4eo.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1175587992 32007 80.91.229.12 (3 Apr 2007 08:13:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 3 Apr 2007 08:13:12 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 03 10:13:08 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HYe8Z-0004pI-11 for ged-emacs-devel@m.gmane.org; Tue, 03 Apr 2007 10:13:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HYeBf-00056e-GI for ged-emacs-devel@m.gmane.org; Tue, 03 Apr 2007 04:16:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HYeBc-00056Z-5n for emacs-devel@gnu.org; Tue, 03 Apr 2007 04:16:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HYeBY-00056L-DG for emacs-devel@gnu.org; Tue, 03 Apr 2007 04:16:15 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HYeBY-00056I-8V for emacs-devel@gnu.org; Tue, 03 Apr 2007 04:16:12 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HYe8P-0002Rj-0V for emacs-devel@gnu.org; Tue, 03 Apr 2007 04:12:57 -0400 Original-Received: from quinscape.de (pd95b0fdb.dip0.t-ipconnect.de [217.91.15.219]) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id KAA06647 for ; Tue, 3 Apr 2007 10:12:47 +0200 X-Delivered-To: Original-Received: (qmail 10830 invoked from network); 3 Apr 2007 08:12:48 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 08:12:48 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 25FF3C3A49; Tue, 3 Apr 2007 10:12:48 +0200 (CEST) In-Reply-To: (Richard Stallman's message of "Tue\, 03 Apr 2007 03\:46\:59 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 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:68972 Archived-At: Richard Stallman writes: > > $ cp ../pic.png pic1.png > > open the first file > > rename pic1.png to pic3.png: > > revisit the first file > > The image shows up as a small square rather than the real image. > > This is because the underlying image file, pic1.png, is gone. I think > this is not worth fixing at this point. > > It is clearly a bug, and we should try to fix it. I can't see that. > What causes this bug? What data structure still refers > to the old file name, and has not been updated to the new one? The image property. And Emacs does not track the arbitrary renaming of files outside of it. We can either let the image property refer to the file, or we can use a :data property. The latter, however, would require duplicating the image content into that property, so we'll permanently have a) the image buffer with the content b) the :data property with the content c) the image cache with the content That's a bit much. I think it is fine to refer to the file as long as Emacs is not used for editing images. And I would even go so far to say that we could junk the buffer contents and reload it when exiting image mode. In a somewhat less extreme manner, one could junk the buffer contents and _move_ them into a :data property, then move them out again when exiting image mode. That way the content would stay in the buffer, would not rely on the external file, and would not take up extra space. Another possibility would be to allow one or several of a) a buffer b) an overlay (use the covered text) c) a cons of two markers d) t (use the data covered by the overlay itself) as an argument to the :data parameter of an image property. Then we would not need to copy material back and forth. One would need to think about what could happen when the material references by :data changes. While this may make for interesting additions (especially when talking about simple formats like pnm which can be easily manipulated within Emacs), the current state of affairs is _perfectly_ usable, reasonably understandable and consistent and fit for release. -- David Kastrup