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