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

[AKIYAMA Kouhei]

Thank you for answering my question. I now understand better.

> 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 was surprised when I saw the implementation of image-dired. It's
okay to specify an image file that doesn't yet exist! And then it
calls clear-image-cache later to prompt a reload. I don't think I
would have thought of that.

I would like to confirm one thing: specifying an image file that does
not yet exist in the display text property is a supported usage,
right?

I fully understand wanting to keep the message for diagnostic
purposes. However, I feel that it is going too far to uniformly issue
an error when specifying a non-existent image file is a normal
usage. Is it possible to provide a way to suppress the message by
adding some text property, image descriptor property, or some other
form? I'm not familiar with the parts written in C, but would you be
hesitant to add one just for such a small purpose?

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

>From a simple perspective, it seems that there is no need to specify
an image for the display property of thumbnails that haven't been
created yet (ideally, something like a creating indicator text or
image could be displayed instead). After creation is complete, the
display property can be changed. In other words, when an thumbnail
image is created in image-dired-create-thumb-1 or
image-dired-create-thumb-2, the text property is changed instead of
clear-image-cache (a method is also needed to determine the text
position corresponding to the image file name). If an ordinary
programmer were to create something like image-dired, this seems like
a reasonable approach, so is there any particular inconvenience that
led to the current implementation?

Is a mechanism like jit-lock really necessary? I'm not sure of the
exact timing of when images added outside of the visible area are
loaded. Could there be any differences in image loading between using
image-clear-cache for reloading and changing the display property?

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

I've heard that ImageMagick has had some issues in the past. I imagine
you've had a lot of difficulties.

I really like the way Emacs tries to do everything on its own. I think
it would be great if in the future it were possible to create
thumbnails on all platforms using only Emacs.

However, this is not about building it with Emacs, but only about
using it as an external command. Isn't it outdated that convert is the
current default? Rather than using convert, wouldn't it be better to
use magick and have convert and gm available as options?

> > 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?

This is incorrect. The "queue" being referred to here is the
image-dired-queue. In other words, while there are pending conversion
jobs, no checks are made, but once the conversion jobs are cleared,
the check is performed the next time a conversion job is added.

When you try to create multiple thumbnails at once (using
image-dired-show-all-from-dir or by marking and adding), many jobs
will accumulate in the image-dired-queue. It will only check the first
one.

You didn't say that users should be able to install ImageMagick while
Emacs is creating thumbnails, right? That would mean that the
installation process and the call to convert.exe could happen at the
same time, and there's no guarantee that convert.exe will work
correctly.

Skipping the test when only one thumbnail is being created doesn't
make much difference. The real issue arises when multiple thumbnails
are being created at once, causing the slow test process to be
repeated for each thumbnail. And testing for the existence of convert
and switching methods while creating many thumbnails is not only
wasteful but even harmful.

The second idea is to perform the check just once when the user
executes the command to add thumbnails. This is perfectly reasonable
since the user would expect thumbnails to be added based on the
current setup at that moment.

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

I feel like that idea is a little too tied to the Unix way. Each OS
has its own way, and software placement is one of them. Separating
directories for each application is not something that is unique to
MS-Windows. Even Emacs Lisp can be used as needed to either put it in
a single lisp directory or to put it in a separate directory for each
package (come to think of it, Emacs's load-path also has some
troublesome points). However, since such a choice is possible, I do
not intend to interfere with it.

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

Understood, I respect your opinion. I will withdraw the idea of
testing only once at the first time.

--
# Longer paragraphs require more translation effort and less accuracy.
# If you don't understand the meaning, please let me know.
# In machine translation, "I" is often written as "you" or "we"!
AKIYAMA Kouhei
misohena@gmail.com