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

[AKIYAMA Kouhei <misohena@gmail.com>]

> > 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?
>
> No, it isn't.  An image file specified in a 'display' property should
> already exist.  The fact that you don't see any serious consequences
> when the file does not exist is that the display code catches any
> errors and recovers after logging the error message in *Messages*, but
> this is generally deemed as a bug that needs to be fixed in the Lisp
> program which caused that.

That's surprising. So, the current image-dired design needs to be fixed.

> > 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?
>
> We could perhaps do that, but I'm not sure we should.  It seems to be
> a way to exonerate unclean Lisp programming.

I agree that this doesn't look very good, and in this case, it's
already checked that it doesn't exist, so having to check again would
be inefficient.

> > >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?
>
> This could also be am okay implementation.

If specifying a non-existent image file is not a normal usage, then at
the very least, this level of implementation will be necessary.

Before discussing the issue of whether to use synchronous or
asynchronous methods when using w32image-create-thumbnail, it seems
necessary to resolve this first.

> > 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?
>
> MS-Windows users of Emacs are unlikely to have 'convert' unless they
> have an Emacs compiled with ImageMagick support.  It's possible, of
> course, just not likely.

That's probably true.

After all, is the default "convert" just for people who haven't
explicitly set image-dired-cmd-create-thumbnail-program and want to
keep using "convert"?

By the way, why didn't you include the option to use
w32image-create-thumbnail in image-dired-cmd-create-thumbnail-program?
In other words, wouldn't it have been okay to define it like this:

(defcustom image-dired-cmd-create-thumbnail-program
  (cond
   ((executable-find "gm") "gm")
   ((and (not (image-dired--probe-thumbnail-cmd "convert"))
         (fboundp 'w32image-create-thumbnail))
    'built-in-function)
   (t "convert"))
  "..."
  :type (if (fboundp 'w32image-create-thumbnail)
            '(choice (const built-in-function) file)
          'file)
  :version "29.1")

(I don't know whether it's better to separate the variables.)

This way, even if convert is installed, users who want to try the
w32image-create-thumbnail function can explicitly select it.

Installing GraphicsMagick doesn't suddenly make 'gm' used for
thumbnail creation. Similarly, is it really okay for 'convert' to
suddenly be used after installing ImageMagick?

> > > 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.
>
> The scenario I had in mind was that the user installs ImageMagick,
> then visits a directory with images.  In this case, the queue will not
> be empty, so Emacs would not check for the availability of 'convert',
> which is not what the user will expect.

Sorry, I don't quite understand this. So you start Emacs, then install
ImageMagick, then go to the directory with the images and run M-x
image-dired, etc.? Of course the queue is empty at first. Are you
talking about what happens when you move to another directory after
that? In that case, there are two situations: the queue is sometimes
empty and sometimes not. When it's empty, convert is checked
again. When it's not empty, it means the previous thumbnail creation
process is still ongoing. This is when the PC is working hard to
create thumbnails by starting many processes. It's hard to imagine
installing ImageMagick during that time. If you try to install it, as
I wrote before, with the current implementation, there is a
possibility that the installation process and the execution of
convert.exe will overlap (for example, if convert.exe is installed but
the necessary dll is not yet installed, it may be determined that
convert can be used, but image conversion may result in an
error). Even if the switch is successful, the quality of the
thumbnails will change at an unexpected point in time. I thought it
would be better to switch when the queue is empty than the current
implementation.

> > 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.
>
> Yes, that'd be reasonable as well.  But note that a user could add thumbnails while some thumbnails are already being created...

Well, this seems to be a better idea. Of course, all timing must be
considered. It takes more effort to implement than the above idea in
many ways, so I'm not sure if it's okay, but if you don't mind. I
guess the queue will also contain information about which command to
execute.