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

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

[AKIYAMA Kouhei]

When using image-dired without ImageMagick or GraphicsMagick
available, operations could not be performed until all thumbnails had
been created.

* Steps to reproduce

 1. Open a command prompt (cmd.exe)
 2. wget https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30/emacs-30.0.91.zip
 3. unzip emacs-30.0.91.zip
 4. set PATH=c:\Windows\system32
    (Make sure ImageMagick is not included)
 5. .\bin\emacs -Q --init-directory=%CD%\.emacs.d
    (Start with a brand new .emacs.d)
 6. C-x C-f <my photo directory> RET
    (<my photo directory> contains 247 jpg files)
 7. M-x image-dired RET RET
 8. After 36 seconds, the *image-dired* buffer is open with all
    thumbnails converted.

    (The aspect ratio of the image will be ignored and it will not be
    rotated correctly, but that's a separate issue.)

Let me compare it with my previous setup. I'm using MSYS2's magick.exe.

 9. C-x C-c
    (exit emacs)
 10. rmdir /S .emacs.d
     (Remove thumbnails)
 11. .\bin\emacs -Q --init-directory=%CD%\.emacs.d
 12. (setq image-dired-cmd-create-thumbnail-program
       "c:/msys64/ucrt64/bin/magick.exe"
       image-dired-cmd-create-thumbnail-options
       '("convert" "-auto-orient" "-define" "jpeg:size=%wx%h" "-size" "%wx%h"
         "%f[0]" "-resize" "%wx%h>" "-strip" "jpeg:%t"))
 13. C-x C-f <my photo directory> RET
 14. M-x image-dired RET RET
 15. After 5 seconds the *image-dired* buffer is opened. Only the first
     few thumbnails have been converted.
 16. After 19 seconds (from start) all thumbnails have been converted
     and displayed.

* Cause:

The cause is the image-dired-thumb-queue-run function and the
image-dired-create-thumb function that calls it.

The image-dired-create-thumb function executes
image-dired-thumb-queue-run with a delay using (run-at-time 0 nil
#'image-dired-thumb-queue-run). Later, image-dired-thumb-queue-run is
called all at once in succession.

In the latter half of the image-dired-thumb-queue-run function,
image-dired-create-thumb-2 is executed with a delay using
(run-with-timer 0.05 nil #'image-dired-create-thumb-2 orig-file
thumb-file). There is no limit to the number of timers, so a new timer
is added even if one has already been scheduled. Therefore, all
thumbnails are created continuously and without interruption. The
number of seconds, 0.05, is not very meaningful.

(I apologize if these behaviors were intended)

* Solution:

You can achieve a similar behavior by limiting the number of images
when using the image-dired-create-thumb-2 function.

I tried modifying the latter half of the image-dired-thumb-queue-run
function as follows and tested it again.

    ;; We are on MS-Windows with ImageMagick/GraphicsMagick, and need to
    ;; generate thumbnails by our lonesome selves.
    (while (and image-dired-queue
                (< image-dired-queue-active-jobs 1))
      (cl-incf image-dired-queue-active-jobs)
      (let* ((job (pop image-dired-queue))
             (orig-file (car job))
             (thumb-file (cadr job)))
        (run-with-timer 0.00 nil
                        (lambda (a b)
                          (cl-decf image-dired-queue-active-jobs)
                          (image-dired-create-thumb-2 a b))
                        orig-file thumb-file)))

As a result, the *image-dired* buffer appeared after 17 seconds, and
all thumbnails were created after 34 seconds.

The performance has dropped, but this is because
image-dired--probe-thumbnail-cmd is slow.  So I set it as follows to
avoid matching "convert", and avoided the slow check process.

  (setq image-dired-cmd-create-thumbnail-program "")

I tested it again, and the *image-dired* buffer appeared after 5
seconds, and all thumbnails were created after 7 seconds. This was
faster than when I used the magick command (despite running it in
multiple processes), and I got very good results.  I think it's better
not to call image-dired--probe-thumbnail-cmd too frequently.


Recently, I have been increasingly using image-dired for organizing my
photos. I look forward to seeing how image-dired continues to
evolve. Thank you.
-------
In GNU Emacs 30.0.91 (build 2, x86_64-w64-mingw32) of 2024-09-12 built
 on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.19045.4894)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: ja_JP.CP932
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort emacsbug mail-extr message sendmail mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
cl-loaddefs cl-lib japan-util rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 58721 16525) (symbols 48 6296 1) (strings 32 17245 3277)
 (string-bytes 1 453015) (vectors 16 10080)
 (vector-slots 8 252453 22466) (floats 8 32 648)
 (intervals 56 1127 635) (buffers 992 11))

-- 
# This report was created using machine translation.
AKIYAMA Kouhei
misohena@gmail.com

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

[Eli Zaretskii]

> From: AKIYAMA Kouhei <misohena@gmail.com>
> Date: Fri, 13 Sep 2024 22:07:48 +0900
> 
> When using image-dired without ImageMagick or GraphicsMagick
> available, operations could not be performed until all thumbnails had
> been created.

Thank you for your report and the research that went into it.

When you speed up the display of the buffer, don't you see in
*Messages* error messages about missing files that cannot be
displayed?  The default values of delays and timers were chosen so as
to minimize these error messages for some reasonable amounts of images
in a directory (your 274 images is way larger than what I had in
mind).

image-dired--probe-thumbnail-cmd is called frequently because the user
could install ImageMagick at some point, and I didn't feel like adding
complicated logic to allow detection of that that is cheaper.  But if
you have practical suggestions for how to make these tests more seldom
without disabling them completely, that could be a good improvement.

In general, the non-ImageMagick implementation was intended to be a
fallback, for those who cannot or will not install ImageMagick.  It is
deliberately synchronous, but I think it performs well enough to be
usable.

Granted, improvements to the code are welcome, but if they make the
redisplay error messages appear in more cases, I think such a change
would be for the worse, because users can rightfully think Emacs has a
bug.

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

[AKIYAMA Kouhei]

Thank you for your response.
# I forgot to CC it so I'll resend it. Sorry.

The error message you are referring to is "Unable to load image (image
:type jpeg ...)," correct? 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? Do you believe it
would be better to change to synchronous processing and suppress the
error message even when using ImageMagick?

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? If we fix that, it might be possible to
suppress the error message even in asynchronous processing.

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.

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

Honestly, I believe a single check at startup should be
sufficient. Even if ImageMagick (with legacy utilities) is installed
while Emacs is running, it won’t be accessible unless the PATH
environment variable is updated. In the end, restarting Emacs is the
quickest solution. 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).
--
# This report was created using machine translation.
AKIYAMA Kouhei
misohena@gmail.com

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

[Eli Zaretskii]

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

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

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

[Eli Zaretskii]

> From: AKIYAMA Kouhei <misohena@gmail.com>
> Date: Sat, 14 Sep 2024 20:18:04 +0900
> Cc: 73231@debbugs.gnu.org
> 
> > 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?

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.

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

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

This could also be am okay implementation.

> Is a mechanism like jit-lock really necessary?

Not necessary, no.  I just mentioned it as an existing infrastructure
that could be used in this case.

> I'm not sure of the exact timing of when images added outside of the
> visible area are loaded.

They are loaded when Emacs is about to display them, or slightly
before that.  When redisplay kicks in, it usually examines the portion
of the buffer that is slightly more than what will be shown in the
window.

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

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.

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

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

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

Maybe so, but it's much simpler in practice (all the programs work
together in unison seamlessly), and Emacs is a Unix program after all,
so it already uses a lot of Unix conventions, like the bin/, lib/, and
libexec/ directories where it installs its files.

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

[AKIYAMA Kouhei]

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

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

[Eli Zaretskii]

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

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

[AKIYAMA Kouhei]

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

What are the trouble for runtime tests? If this is implemented,
obviously no check for the existence of the command will be performed
at runtime. If necessary, the user can change the settings of the
program that creates thumbnails by themselves (after installing
ImageMagick or GraphicsMagick). In other words, first create
thumbnails with the built-in function (w32image-create-thumbnail), and
if a user is dissatisfied with them, they can install either
ImageMagick or GraphicsMagick and specify the program they installed
via M-x customize-variable
image-dired-cmd-create-thumbnail-program. Isn't this the same for most
other parts of Emacs? For example, if a user is dissatisfied with grep
and installs ripgrep, they will have to manually change grep-command
themselves. Isn't it the same? Why does Emacs automatically determine
the thumbnail creation method without the user's permission?

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

If the quality of ImageMagick is bad as you say, the convert command
may have a bug that makes it impossible to convert some images. Also,
if w32image-create-thumbnail is improved in the future (at least if
the aspect ratio and rotation are resolved), people will want to use
it. It seems that w32image-create-thumbnail is faster in many
cases. To be honest, I don't understand why you want to prioritize the
even more legacy command of ImageMagick, which you dislike.

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

Ah, sorry. That was a mistake on my part. The queue is definitely not
empty when queue-run is first called. Checking whether the queue is
empty would be meaningless unless it is done before the first job is
added to the queue. Or I need to use the approach you showed.

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

So when the queue is empty, just after the last of the series of
thumbnails has been created, we set it back to 'unknown.

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

[Eli Zaretskii]

> From: AKIYAMA Kouhei <misohena@gmail.com>
> Date: Sun, 15 Sep 2024 16:32:34 +0900
> Cc: 73231@debbugs.gnu.org
> 
> > > 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.
> 
> What are the trouble for runtime tests? If this is implemented,
> obviously no check for the existence of the command will be performed
> at runtime.

We are miscommunicating.  A defcustom is evaluated each time Emacs
starts up and loads the Lisp package which includes the defcustom.
That is what I meant by "run-time tests", as opposed to build-time
tests, which are done when Emacs is built (which for Windows users in
many cases means on a different system with different installed
libraries).

Because the test is performed when the package is loaded, it might
make different decisions that the user expects, because the user
doesn't control when the package is loaded.  For example, if
ImageMagick is installed after this defcustom is evaluated, its value
will be incorrect from the user's POV.

> If necessary, the user can change the settings of the
> program that creates thumbnails by themselves (after installing
> ImageMagick or GraphicsMagick).

I'm talking about the default value.  Customizing this will make the
value fixed, not dynamically-decided.

> In other words, first create
> thumbnails with the built-in function (w32image-create-thumbnail), and
> if a user is dissatisfied with them, they can install either
> ImageMagick or GraphicsMagick and specify the program they installed
> via M-x customize-variable
> image-dired-cmd-create-thumbnail-program. Isn't this the same for most
> other parts of Emacs? For example, if a user is dissatisfied with grep
> and installs ripgrep, they will have to manually change grep-command
> themselves. Isn't it the same? Why does Emacs automatically determine
> the thumbnail creation method without the user's permission?

Emacs does this in many other cases, so this is hardly an exception.

> > > 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.
> 
> If the quality of ImageMagick is bad as you say, the convert command
> may have a bug that makes it impossible to convert some images. Also,
> if w32image-create-thumbnail is improved in the future (at least if
> the aspect ratio and rotation are resolved), people will want to use
> it. It seems that w32image-create-thumbnail is faster in many
> cases. To be honest, I don't understand why you want to prioritize the
> even more legacy command of ImageMagick, which you dislike.

It's okay to disagree, but I stand by my opinion, and will not change
this unless enough users request that.  Primarily because it's a
complication, both technically and from user POV, requiring
documentation etc.

> > 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.
> 
> So when the queue is empty, just after the last of the series of
> thumbnails has been created, we set it back to 'unknown.

That's not what I had in mind.  I thought it should stay at its nil/t
value until the user invokes that hypothetical command to perform the
check again and set the variable to the value produced by the check.

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

[AKIYAMA Kouhei]

> >>> 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.
> >
> > What are the trouble for runtime tests? If this is implemented,
> > obviously no check for the existence of the command will be performed
> > at runtime.
>
> We are miscommunicating.
> A defcustom is evaluated each time Emacs starts up and loads the
> Lisp package which includes the defcustom.

Of course.

> That is what I meant by "run-time tests",

Ah, I misunderstood. You're talking purely about evaluation while
Emacs itself is running. I had actually considered the possibility
that you meant it that way, but there was something that seemed
inconsistent with how I interpreted your comment, so I ignored that
possibility. Sorry.

> Because the test is performed when the package is loaded, it might
> make different decisions that the user expects, because the user
> doesn't control when the package is loaded.  For example, if
> ImageMagick is installed after this defcustom is evaluated, its
> value will be incorrect from the user's POV.

Isn't that the same with GraphicsMagick? In your opinion, that means
the (executable-find "gm") part is also incorrect from the user's POV?

> > If necessary, the user can change the settings of the
> > program that creates thumbnails by themselves (after installing
> > ImageMagick or GraphicsMagick).
>
> I'm talking about the default value.  Customizing this will make the
> value fixed, not dynamically-decided.

Of course I'm talking about default values. Of course the value is
fixed when the package is loaded. And I thought that was acceptable
because I saw (executable-find "gm") written in defcustom. Is it
wrong?

> > In other words, first create
> > thumbnails with the built-in function (w32image-create-thumbnail), and
> > if a user is dissatisfied with them, they can install either
> > ImageMagick or GraphicsMagick and specify the program they installed
> > via M-x customize-variable
> > image-dired-cmd-create-thumbnail-program. Isn't this the same for most
> > other parts of Emacs? For example, if a user is dissatisfied with grep
> > and installs ripgrep, they will have to manually change grep-command
> > themselves. Isn't it the same? Why does Emacs automatically determine
> > the thumbnail creation method without the user's permission?
>
> Emacs does this in many other cases, so this is hardly an exception.

Even if you say "many other cases," it's still a minority when viewed
in the context of Emacs as a whole, right? I was simply curious about
why a different decision was made here compared to the method adopted
by the majority, so I asked. I'm not saying you should do it that
way. I just thought there might be a hint in the reasoning that could
help me understand something.

> >>> 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.
> >
> > If the quality of ImageMagick is bad as you say, the convert command
> > may have a bug that makes it impossible to convert some images. Also,
> > if w32image-create-thumbnail is improved in the future (at least if
> > the aspect ratio and rotation are resolved), people will want to use
> > it. It seems that w32image-create-thumbnail is faster in many
> > cases. To be honest, I don't understand why you want to prioritize the
> > even more legacy command of ImageMagick, which you dislike.
>
> It's okay to disagree, but I stand by my opinion, and will not
> change this unless enough users request that.  Primarily because
> it's a complication, both technically and from user POV, requiring
> documentation etc.

I don't agree or disagree.

The reason is "it's a complication, both technically and from user
POV, requiring documentation etc." That's what I wanted to hear. I
will never tell you to do something you don't want to do. Please calm
down.

> >> 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.
> >
> > So when the queue is empty, just after the last of the series of
> > thumbnails has been created, we set it back to 'unknown.
>
> That's not what I had in mind.

Of course it's not the same.

> I thought it should stay at its nil/t value until the user invokes
> that hypothetical command to perform the check again and set the
> variable to the value produced by the check.

That's fine, but wouldn't it be more natural to have them set a
customization variable rather than calling the command? Well, maybe
you don't think so.

I didn't fully understand your thoughts on the existence test of the
convert command, but I have some understanding. I hope this was
helpful for people who have the same question as me. Of course, you
are free to decide how to do it.

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

[Eli Zaretskii]

> From: AKIYAMA Kouhei <misohena@gmail.com>
> Date: Sun, 15 Sep 2024 18:33:52 +0900
> Cc: 73231@debbugs.gnu.org
> 
> > Because the test is performed when the package is loaded, it might
> > make different decisions that the user expects, because the user
> > doesn't control when the package is loaded.  For example, if
> > ImageMagick is installed after this defcustom is evaluated, its
> > value will be incorrect from the user's POV.
> 
> Isn't that the same with GraphicsMagick? In your opinion, that means
> the (executable-find "gm") part is also incorrect from the user's POV?

Yes, IMO.  If GraphicsMagick is installed after the package is loaded
by Emacs, the result will be incorrect.

> > > If necessary, the user can change the settings of the
> > > program that creates thumbnails by themselves (after installing
> > > ImageMagick or GraphicsMagick).
> >
> > I'm talking about the default value.  Customizing this will make the
> > value fixed, not dynamically-decided.
> 
> Of course I'm talking about default values. Of course the value is
> fixed when the package is loaded. And I thought that was acceptable
> because I saw (executable-find "gm") written in defcustom. Is it
> wrong?

My point is that customizing the value is usually followed by saving
the customizations, which will cause all the future Emacs session to
use the same fixed value, bypassing the dynamic decision in the
original value.

> > > In other words, first create
> > > thumbnails with the built-in function (w32image-create-thumbnail), and
> > > if a user is dissatisfied with them, they can install either
> > > ImageMagick or GraphicsMagick and specify the program they installed
> > > via M-x customize-variable
> > > image-dired-cmd-create-thumbnail-program. Isn't this the same for most
> > > other parts of Emacs? For example, if a user is dissatisfied with grep
> > > and installs ripgrep, they will have to manually change grep-command
> > > themselves. Isn't it the same? Why does Emacs automatically determine
> > > the thumbnail creation method without the user's permission?
> >
> > Emacs does this in many other cases, so this is hardly an exception.
> 
> Even if you say "many other cases," it's still a minority when viewed
> in the context of Emacs as a whole, right?

It is used almost everywhere where some function can be provided
either by an external program or by an internal Emacs API.

> I was simply curious about
> why a different decision was made here compared to the method adopted
> by the majority, so I asked. I'm not saying you should do it that
> way. I just thought there might be a hint in the reasoning that could
> help me understand something.

Like I said, the main reason was technical: I wanted to make sure the
test detects when 'convert' or 'gm' is installed, even if they are
installed while the Emacs session is already running and it already
loaded the image-dired package.

> > I thought it should stay at its nil/t value until the user invokes
> > that hypothetical command to perform the check again and set the
> > variable to the value produced by the check.
> 
> That's fine, but wouldn't it be more natural to have them set a
> customization variable rather than calling the command?

Maybe.  We'll have to see when this becomes relevant.

> I didn't fully understand your thoughts on the existence test of the
> convert command, but I have some understanding. I hope this was
> helpful for people who have the same question as me. Of course, you
> are free to decide how to do it.

Thanks.