From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#73231: 30.0.91; image-dired cannot be operated until all thumbnails are created (MS-Windows) Date: Sat, 14 Sep 2024 09:47:28 +0300 Message-ID: <86v7yyiven.fsf@gnu.org> References: <861q1n1z2z.fsf@gmail.com> <867cbfk0e5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17133"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73231@debbugs.gnu.org To: AKIYAMA Kouhei Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 14 08:48:20 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1spMZu-0004MN-VZ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Sep 2024 08:48:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spMZX-0007hB-Mw; Sat, 14 Sep 2024 02:47:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spMZV-0007Xz-9D for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2024 02:47:53 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1spMZU-00040f-MF for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2024 02:47:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=NBg3orJiSJpwtkcOOJRiO1QXRODVPf/ptC9EGgtkDAw=; b=B8EM6ns6/BPFtWUgar0oUaepctFCLiEqXrotDx0df8+jdhxb2KdghAhRvDFHnv8aJmRq+Q74Z4nGpTRYRfuRnVesKm4L8lg9h++CMyDzY8aMPFNBTRirybKk0Vigy+3oEheq137MhQl5dk/kAYZqoDS5LgtwEnPAyGEmhENXPmSWL9tWgr6dUUDTHK2NENbhfVL7sDBFO4FQ2TLCdfy0ZfEGctf7UCIXQFy8QPeVDYIWzcmjazKsW53b4TbIJASCtRleA2h52N3tyHR4693wFWrRrMg+emh6AFvgNM93ZNZxRChxXuOo5MfACKV3GXMewypDtgvV3K3KSp1DgNvPSg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1spMZe-0008Qj-GE for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2024 02:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2024 06:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73231 X-GNU-PR-Package: emacs Original-Received: via spool by 73231-submit@debbugs.gnu.org id=B73231.172629647032386 (code B ref 73231); Sat, 14 Sep 2024 06:48:02 +0000 Original-Received: (at 73231) by debbugs.gnu.org; 14 Sep 2024 06:47:50 +0000 Original-Received: from localhost ([127.0.0.1]:44561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spMZS-0008QH-0n for submit@debbugs.gnu.org; Sat, 14 Sep 2024 02:47:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spMZQ-0008Q2-CI for 73231@debbugs.gnu.org; Sat, 14 Sep 2024 02:47:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spMZA-0003sO-Mo; Sat, 14 Sep 2024 02:47:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=NBg3orJiSJpwtkcOOJRiO1QXRODVPf/ptC9EGgtkDAw=; b=lVOQShbUvxsP2c+gHoFl KS4JUZDgNr50/4jk3UuvnlKl8+zZTlbi0ziTNNPV1yiEnyqk41IVXd6YfBEFAXmICugLYSTfGYOiK jJ8LcAYxXmdU/1sG5o9LAdV6BvVhv1Ppmw1PVyISSlJLawhFSLGJFEdIK+aOue9S3mJy44ZnrX5jZ 8um57kPMUw93npjwnfpK3X+zVk5eU2W1BhgHUfiANC9DdHfxSUYIhxGAWw2jny3SbSwuBR01Ua9uA xgxiuF38mnd0KW2s9FZ8eMKAY+Ro16cApVTop5tlg1xyBGTTUH0Ielk+Fqb1j6nfBXmjkkn2YoLX8 FBvTSxatbOKU3g==; In-Reply-To: (message from AKIYAMA Kouhei on Sat, 14 Sep 2024 09:25:11 +0900) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:291685 Archived-At: > From: AKIYAMA Kouhei > 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.