Re: address@hidden: display problem after renaming open image files]

[David Kastrup]

Richard Stallman <address@hidden> 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