bug#59902: 30.0.50; Image overlay is not updated until the cursor moves to the overlay

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 59902@debbugs.gnu.org
> Date: Mon, 12 Dec 2022 08:35:43 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Then I don't think I understand what you expect Emacs to do in these
> > cases.  We have no idea when the image file is replaced, and cannot
> > have such an idea without examining the file at high enough frequency.
> > Doing this "from time to time" is going to miss some changes, or take
> > note of them too late.  What else is possible?
> 
> For example, `create-image' could accept optional argument to update the
> cached image if the file modification time is newer than it was when the
> image was cached.

Patches welcome.  We currently hash only the spec itself, and don't
pay attention to the file's meta-data.  (I also think that if we go
this way, file modification time alone could be insufficient for 100%
reliability, what with today's fast filesystems.)

> >> Yet, do note that flickering two different image versions when moving
> >> point is unexpected even considering the information you provided.
> >
> > Flickering is expected when you do something that affects a large
> > portion of the Emacs display.  For example, the same will happen if
> > you change a large overlay at high enough frequency.  There's no way
> > around that except not doing that.
> 
> Sorry, I used inaccurate word here.
> What I am referring to here is image overlay displayed old and new image
> when you move the cursor to the overlay and back repeatedly.

Yes, I understood.  My response is still the same.

> > Why was this implementation chosen for whatever feature that produces
> > images?  Emacs doesn't react instantly to changes in disk files that
> > it visits, and here you expect it to do so.  Isn't it possible to
> > implement this in some other way, like have the program produce its
> > image data in a temporary Emacs buffer, then use that buffer's
> > contents for creating an image?  Then I believe the updated image will
> > have a different hash value, and there will be no cache-related
> > collisions.
> 
> It could be possible, but looks like unnecessary complication.
> Also, creating buffers often creates overheads associated with user
> hooks.
> 
> I am not sure if something like
> 
> (let ((revert-without-query '(".")))
> 		      (with-current-buffer (find-file-noselect file)
>                         ;; Do not crown the buffer list.
>                         (unless (string-prefix-p " " (buffer-name))
>                           (setf (buffer-name) (concat " " (buffer-name))))
> 			(buffer-string)))
> 
> is not going to cause significant slowdowns.

Sorry, you lost me here: how is the above snippet relevant to what I
proposed as an alternative implementation?