bug#73231: 30.0.91; image-dired cannot be operated until all thumbnails are created (MS-Windows)

[Eli Zaretskii <eliz@gnu.org>]

> From: AKIYAMA Kouhei <misohena@gmail.com>
> Date: Sat, 14 Sep 2024 09:25:11 +0900
> Cc: 73231@debbugs.gnu.org
> 
> The error message you are referring to is "Unable to load image (image
> :type jpeg ...)," correct?

Yes.

> I had assumed that this message was
> acceptable since it also appears when using ImageMagick. Are you
> suggesting that this behavior was actually a bug?

It certainly looks and feels like a bug: Emacs is requested to display
an image file that doesn't exist.

> Do you believe it
> would be better to change to synchronous processing and suppress the
> error message even when using ImageMagick?

The error message cannot be suppressed, at least not literally,
because it comes from the bowels of the display engine.  Whenever
Emacs is requested to display a non-existent file, the display engine
will always emit this message, and rightfully so.  The message is not
specific to image-dired in any way, it is a generic message, and we do
want to keep it for other cases where Emacs is requested to display
images that don't exist, e.g., because their file names were
misspelled.

> I understand that this error message is being triggered because the
> image file, which does not yet exist, is specified in the "display"
> text property (and because it tries to display when it enters the
> window). Is this correct?

Yes.

> If we fix that, it might be possible to
> suppress the error message even in asynchronous processing.

Yes, but see above: I don't see how this can be suppressed.

The way to fix this is to change the algorithm of image-dired's
display of thumbnails so that it specifies the images to display in
JIT manner, perhaps using the jit-lock machinery or something similar.
When this is done, the fallback code that uses internal Windows APIs
could also be modified to avoid the delays I've introduced in order to
avoid these error messages.

> Regarding the convert.exe issue on MS-Windows, the best solution I
> recommend is using the magick command. In fact, the current Windows
> version of the ImageMagick installer does not install the convert
> command by default (you need to select "Install legacy utilities"). It
> might be a good idea to provide an option that supports ImageMagick
> v7, just as support was added for GraphicsMagick.

The problem with ImageMagick, and the reason why some people (myself
included) don't build Emacs with ImageMagick, are that ImageMagick is
not stable enough: we had in the past quite a few bug reports about
crashes in Emacs caused by ImageMagick.  That is why we generally try
to implement our own solutions for important image-related features
where we can, so that users could build without ImageMagick and still
have features like image rotation.

More generally, fewer external dependencies is a Good Thing for Emacs.

> There are a few ways to reduce tests for the convert command, but the
> most balanced one is to check only when the queue length is 0. You
> probably wouldn't want to insert check code into each image-dired
> command, right? (Though, it seems there are only a limited number of
> commands that trigger thumbnail creation.)

I'm open to ideas.  ("Queue length is 0" would mean you don't test
when a new image directory is visited, right?  If so, I don't think
it's a good idea, because a situation where the user installs
ImageMagick and then goes to visit or re-visit an image directory is
quite possible.)

> Honestly, I believe a single check at startup should be
> sufficient.

That would mean users will have to restart Emacs when they install
'convert'.  I myself hate to restart Emacs (my typical Emacs sessions
keep running for weeks on end), so I wouldn't want to force users to
do that.

> Even if ImageMagick (with legacy utilities) is installed
> while Emacs is running, it won’t be accessible unless the PATH
> environment variable is updated.

This assumes the typical (and IMNSHO incorrect) way of installing
stuff on Windows, whereby each package is installed into its own
directory, which then requires to add some subdirectory to PATH.  A
much better way of installing packages is to have a single bin
directory for all the executables and shared libraries, like on a
typical Unix system.  In that case, not PATH adjustment is ever
needed.

> In the end, restarting Emacs is the quickest solution.

Restarting Emacs means you lose information.  Even if you use
desktop.el, saveplace, and other similar optional features, some
information is lost.

> Of course, this is a different story if there is already a directory
> (e.g., MSYS2 or Cygwin’s bin) prioritized over System32 in your
> PATH, where you can place convert.exe (for safety, I have MSYS2's
> bin placed after System32).

That is exactly what I want to support.