From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: [dooglus@gmail.com: display problem after renaming open image files] Date: Thu, 05 Apr 2007 19:55:13 -0400 Message-ID: <87zm5mz89q.fsf@stupidchicken.com> References: <87ircfu4eo.fsf@stupidchicken.com> <868xd998qo.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1175817219 13422 80.91.229.12 (5 Apr 2007 23:53:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 5 Apr 2007 23:53:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 06 01:53:20 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 1HZblV-0004If-2u for ged-emacs-devel@m.gmane.org; Fri, 06 Apr 2007 01:53:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HZbou-0001KL-UV for ged-emacs-devel@m.gmane.org; Thu, 05 Apr 2007 19:56:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HZbor-0001KF-LL for emacs-devel@gnu.org; Thu, 05 Apr 2007 19:56:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HZboq-0001H0-6H for emacs-devel@gnu.org; Thu, 05 Apr 2007 19:56:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HZbop-0001Go-Vb for emacs-devel@gnu.org; Thu, 05 Apr 2007 19:56:44 -0400 Original-Received: from cyd.mit.edu ([18.19.1.138]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HZblN-0002FV-CJ; Thu, 05 Apr 2007 19:53:09 -0400 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id 0EAE44EB5B; Thu, 5 Apr 2007 19:55:13 -0400 (EDT) In-Reply-To: (Richard Stallman's message of "Thu\, 05 Apr 2007 19\:13\:22 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.97 (gnu/linux) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:69103 Archived-At: Richard Stallman writes: > 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. > > I think that is a fine solution, and should be easy to implement. Whatever makes you think that it's easy to implement? On the contrary, this will involve deep surgery in image.c. There are a large number of functions in image.c that assume the image specification is either a filename or a string. Each of the image types has at least one function that queries a `struct image' for either QCdata or QCfile, and handles these two cases appropriately. Adding a `buffer overlay' option will involve changing each and every one of these functions to handle this new case. These changes are not trivial either, because the functions for different image types access the image structs in different ways, depending on the requirements of the external image library. For all practical purposes, the current behavior is fine. After all, image-mode (currently) functions as an image viewer, not an image editor. So if you move the underlying image file, no one will be surprised that you can't view the image anymore! Plenty of image viewing programs have this behavior (see gqview for example.) Seriously, let's postphone this till after the release.