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

Previous Next

Full log

Message #38 received at 73231 <at> debbugs.gnu.org (full text, mbox):

From: AKIYAMA Kouhei <misohena <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73231 <at> debbugs.gnu.org
Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all
 thumbnails are created (MS-Windows)
Date: Sun, 15 Sep 2024 18:33:52 +0900

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.