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: Sun, 15 Sep 2024 09:24:30 +0300 Message-ID: <86jzfde8o1.fsf@gnu.org> References: <861q1n1z2z.fsf@gmail.com> <867cbfk0e5.fsf@gnu.org> <86v7yyiven.fsf@gnu.org> <8634m2h3cq.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34898"; 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 Sun Sep 15 08:25:17 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 1spihA-0008ve-Ev for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Sep 2024 08:25:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spigo-0006qG-CN; Sun, 15 Sep 2024 02:24:54 -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 1spigm-0006po-5z for bug-gnu-emacs@gnu.org; Sun, 15 Sep 2024 02:24:52 -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 1spigl-0006tV-Qy for bug-gnu-emacs@gnu.org; Sun, 15 Sep 2024 02:24:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=C1Q3RcsOx1UUJnpjpvxtV9C827gxaoUjDUC++oCqEtM=; b=e0psv16UEL2r4+LXT2sx/I6WLXtKk31Eo6BlEmwfeVaL2G/KhBjtAbG94FPOFm03FvoEv07s5F2NtTB5nglhfEjzgQIK+Uoym+F1OOb3yqTe0jcgpc5yYTN6oDK4NblHJf4yiCXZgmh+TDXfK7i6fFO/aMq322WbKIXV643bse03dbdvqs6yJty9VOnRwWwL8TF7HcvVg83x4kNQhQ8ksXiaMX68cYN4U45XpXPYh1poVZtyTjV515RSCWTGJ8GQbtt4STH+KtMnzYXTYPgkyMpeYF1JsclazT9wkwd9sd1Am1RzId2C/zaNp8Qr73uhQPD5cZhtR9sQDX5Oi2y5DA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1spigw-0005fm-7v for bug-gnu-emacs@gnu.org; Sun, 15 Sep 2024 02:25: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: Sun, 15 Sep 2024 06:25: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.172638149821789 (code B ref 73231); Sun, 15 Sep 2024 06:25:02 +0000 Original-Received: (at 73231) by debbugs.gnu.org; 15 Sep 2024 06:24:58 +0000 Original-Received: from localhost ([127.0.0.1]:48177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spigs-0005fK-9F for submit@debbugs.gnu.org; Sun, 15 Sep 2024 02:24:58 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spigq-0005f4-Hg for 73231@debbugs.gnu.org; Sun, 15 Sep 2024 02:24:57 -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 1spigZ-0006sm-Fa; Sun, 15 Sep 2024 02:24:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=C1Q3RcsOx1UUJnpjpvxtV9C827gxaoUjDUC++oCqEtM=; b=GrbYh+1TEVx6 WmT1qV2UPVgtyOD5V1aB1cbR9BCwD7xJufNbYQHHdXiKRPq/BBHx/jBbd/k+q1PAc5AoWfVXZDh+B z+kNEQO4CFPYmb/qGbJuRBJKd8pdzBvK43shsaYF+cOrHnfxQQP+hh+8AA0f0waSWXFLRYpwWtkoF pR0BuaVpTPZRcCelZKAVJog3Wvk2iXygJsDdr057Ko7FsveD9QMyed4NSk8bc4YMHzlhY5XC4gx6I e3FGEFkxFZXcSQT/Ud8whmd7hdoUmd+To1hoZGaZmLoMn4nOVy6ZAb1lHbe/wWBnnXmP+HnMpzcYy C5rPR1QwIa4ndlsR9RNorw==; In-Reply-To: (message from AKIYAMA Kouhei on Sun, 15 Sep 2024 10:25:15 +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:291822 Archived-At: > From: AKIYAMA Kouhei > 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.