[dooglus@gmail.com: display problem after renaming open image files]

[dooglus@gmail.com: display problem after renaming open image files]

[Richard Stallman]

Would someone please DTRT and ack?

------- Start of forwarded message -------
X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL,UNPARSEABLE_RELAY 
	autolearn=no version=3.1.0
From: Chris Moore <dooglus@gmail.com>
To: emacs-pretest-bug@gnu.org
Date: Sun, 01 Apr 2007 14:42:47 +0200
Subject: display problem after renaming open image files

Have a PNG image in /tmp/pic.png, then:

$ cd /tmp
$ mkdir emacs
$ cd emacs
$ cp ../pic.png pic1.png
$ cp ../pic.png pic2.png
$ emacs -Q

open the directory using dired:
  C-x d RET

open the first file in the other window, go back to the direct window, go down a line:
  o C-x o n

open the 2nd file in the other window, close that window, leaving only the dired window:
 o C-x 0

go back to the first file line, rename pic1.png to pic3.png:
p R pic3.png RET

revisit the first file (now called pic3.png):
 f

The image shows up as a small square rather than the real image.

(variations on the above theme, like renaming pic2 instead of pic1, or visiting pic2 after the rename don't seem to cause the problem).



In GNU Emacs 22.0.96.22 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2007-04-01 on trpaslik
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [dooglus@gmail.com: display problem after renaming open image files]

[Chong Yidong]

Richard Stallman <rms@gnu.org> 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.

Re: [dooglus@gmail.com: display problem after renaming open image files]

[Richard Stallman]

    > $ 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.
What causes this bug?  What data structure still refers
to the old file name, and has not been updated to the new one?

Re: [dooglus@gmail.com: display problem after renaming open image files]

[David Kastrup]

Richard Stallman <rms@gnu.org> 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

Re: [dooglus@gmail.com: display problem after renaming open image files]

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

>>     This is because the underlying image file, pic1.png, is gone.  I think
>>     this is not worth fixing at this point.
>>
>> 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

Exactly.  This would be particularly annoying considering people now
routinely handle image sizes in the 10s or 100s of megabytes.

If you move the underlying file outside of Emacs, there's no way for
Emacs to know where you moved it; as far as it can tell, you might as
well have deleted it.

> the current state of affairs is _perfectly_ usable, reasonably
> understandable and consistent and fit for release.

1000% agreement.

Re: [dooglus@gmail.com: display problem after renaming open image files]

[Richard Stallman]

    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.

There's no immediate need for all of these options -- any one would
allow use of the buffer contents, and that would be enough.  Of the
four options, b is both clean and general, and simple.  Would someone
like to implement that?

Re: [dooglus@gmail.com: display problem after renaming open image files]

[Chong Yidong]

Richard Stallman <rms@gnu.org> 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.

Re: [dooglus@gmail.com: display problem after renaming open image files]

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> For all practical purposes, the current behavior is fine.

Indeed it is!

> Seriously, let's postphone this till after the release.

100% agreement.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [dooglus@gmail.com: display problem after renaming open image files]

[Richard Stallman]

    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.)

When you visit a file in Emacs, looking at the buffer is not supposed
to depend on the existence of the file.  The contents of the file are
supposed to be in the buffer.  (That is what a buffer is for.)

That is why this is so clearly a bug.

If I agree to release without fixing this bug now, will you agree
in return to fix the problem next month for Emacs 23?

Re: [dooglus@gmail.com: display problem after renaming open image files]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     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.)
>
> When you visit a file in Emacs, looking at the buffer is not supposed
> to depend on the existence of the file.  The contents of the file are
> supposed to be in the buffer.  (That is what a buffer is for.)
>
> That is why this is so clearly a bug.
>
> If I agree to release without fixing this bug now, will you agree
> in return to fix the problem next month for Emacs 23?

Yes.  The best way to do it is probably to implement the "using an
overlay for the image spec" idea.

As I said, that will require some deep changes in image.c.  It will be
big change, but not conceptually difficult.