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: Sun, 15 Sep 2024 10:25:15 +0900
> Cc: 73231@debbugs.gnu.org
> 
> > > 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 agree.

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

Agreed.

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

This causes trouble for run-time tests, because a defcustom is
evaluated only once, when the package is loaded by Emacs.

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

I didn't expect users who have ImageMagick installed to want to use
w32image-create-thumbnail.  If we hear enough requests for that, we
might need to reconsider.

> 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 don't see why not.  It would be a perfectly understandable user
expectation, IMO.

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

No, not AFAIU, because the moment you invoke image-dired, it starts
thumbnail creation.  So by the time you get to the test, the queue is
already not empty.

Maybe we should simply have a command to check whether an external
tool is installed, and then thumbnail creation will use the results of
that check.  The variable that holds the result of the check could be
initialized to 'unknown, in which case the first thumbnail creation
will perform the check and set the variable to either nil or t.  This
will probably be simpler, although it will now be up to the user to
invoke the command manually if ImageMagick is installed while an Emacs
sessions runs.