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 11:05:46 +0300 Message-ID: <86bk0pe3z9.fsf@gnu.org> References: <861q1n1z2z.fsf@gmail.com> <867cbfk0e5.fsf@gnu.org> <86v7yyiven.fsf@gnu.org> <8634m2h3cq.fsf@gnu.org> <86jzfde8o1.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22538"; 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 10:07:13 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 1spkHn-0005ho-4q for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Sep 2024 10:07:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spkHW-0000sm-47; Sun, 15 Sep 2024 04:06: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 1spkHT-0000sI-5f for bug-gnu-emacs@gnu.org; Sun, 15 Sep 2024 04:06:51 -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 1spkHS-00083O-5n for bug-gnu-emacs@gnu.org; Sun, 15 Sep 2024 04:06:50 -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=/PBMkFaB7498434Lro2UZNVE+uviw8D0DCMo9ldxLE4=; b=ef2SGPcFvV8GTFLkgGgikpgup79PZjEqHKhYUE0mft/8cftLwXAVtPevjECJxxgOcEWcmA5vQ4kZ2owGRcdsNOFC48CxgkKwUD00NWAnKK4L2RjcN7LxFwt1x070ak3YSUCkJ6/Kpp5HkXij+Fto4cvD8+RTaHvZlXySigoWhUS9mAgfr7n6GvFYySWDqmDJs0HUmEa2g5YpkNZ9CPE430W8CdVxw+ZP1iaGL/BQoRKlVi+XbM8exrYeMfDh9FI1JUPAmF/XPf4w+oM1hGCILoA0kbXhy20ElJ8w5nakb5JOhGajCCQhr8kFXCB4Bsob+4O5Xbu7zymMfjR+uC54Dw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1spkHd-00034i-NR for bug-gnu-emacs@gnu.org; Sun, 15 Sep 2024 04:07:01 -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 08:07:01 +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.172638756711733 (code B ref 73231); Sun, 15 Sep 2024 08:07:01 +0000 Original-Received: (at 73231) by debbugs.gnu.org; 15 Sep 2024 08:06:07 +0000 Original-Received: from localhost ([127.0.0.1]:48264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spkGk-00033A-WB for submit@debbugs.gnu.org; Sun, 15 Sep 2024 04:06:07 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spkGj-00032R-JR for 73231@debbugs.gnu.org; Sun, 15 Sep 2024 04:06:06 -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 1spkGS-000814-KU; Sun, 15 Sep 2024 04:05:48 -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=/PBMkFaB7498434Lro2UZNVE+uviw8D0DCMo9ldxLE4=; b=LAgqUspwyvDI uS6FH+Ek120040s97aV24ZkR7TxVBJH74WjzbDtzCD7QfQht7k3rpS4n2IgiUZpSVaZMLgbDKxIGt IiQmnmxRDa8eBLjGMJJIQiTnqVUd/5jVIZTJKBrqMexi+VIn1NFvc0QTMRtfQq6QH6CpLiq8F13hp awNoY4FiermoWYi82nxvEphwc0kXen4frTc2Xu1334hAUdHY3PSAR0cPph9jucj9Ihm//6A3ozEBO 9N2XF0VtED9Q7lsDRXsqbqkvQMyoKQy0MvnLemXjXdfXFieobkPvmPBNz0b5S618o4CS/Ig7ki539 1lP85WOaPevJkopoPwpBHw==; In-Reply-To: (message from AKIYAMA Kouhei on Sun, 15 Sep 2024 16:32:34 +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:291830 Archived-At: > From: AKIYAMA Kouhei > 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.