From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: AKIYAMA Kouhei 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 18:33:52 +0900 Message-ID: References: <861q1n1z2z.fsf@gmail.com> <867cbfk0e5.fsf@gnu.org> <86v7yyiven.fsf@gnu.org> <8634m2h3cq.fsf@gnu.org> <86jzfde8o1.fsf@gnu.org> <86bk0pe3z9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21515"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73231@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 15 12:11:01 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 1spmDd-0005QT-0H for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Sep 2024 12:11:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spmDV-0006uI-1b; Sun, 15 Sep 2024 06:10:53 -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 1spmDT-0006tl-E2 for bug-gnu-emacs@gnu.org; Sun, 15 Sep 2024 06:10: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 1spmDT-0003oe-4g for bug-gnu-emacs@gnu.org; Sun, 15 Sep 2024 06:10:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=s250JL5Z0iOqsAAROsDZQJMgMb2kUUx2lnR8TkIz3O8=; b=F78MmojVickuO7p2orMAKOLQz3vUZ+YmSlZCL8OYMFyOBuJFcj2/x2KvP+mMfEtWsy3/BY+sXW4PAuv1IvaG9oz1KfvhYyt+84EiZbEc++5fXoIg7dY9M2sww+Ymi2N//l8/r9f2vKX7P8fml5mq03FkLyuAgoxfJiDqKBIXTdeK42g/onbxon59F6QcvHX2rfjEVkgtxjaAU2cnhU6L1LIy5qUVAGZTbWqlRkjdeBnCr9ded9IiFQ5Z8BY0gqY0KMz8p4M+0wcR476iEgBKhf1Ho2ufZ3y7JVTJdZw5VwKFMPrPDmtQnif+pqVbjzp6O1w+DlygL6378ignC/9gbQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1spmDe-0001Z7-Qi for bug-gnu-emacs@gnu.org; Sun, 15 Sep 2024 06:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: AKIYAMA Kouhei Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Sep 2024 10:11: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.17263950315964 (code B ref 73231); Sun, 15 Sep 2024 10:11:02 +0000 Original-Received: (at 73231) by debbugs.gnu.org; 15 Sep 2024 10:10:31 +0000 Original-Received: from localhost ([127.0.0.1]:48464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spmD8-0001Y1-Cr for submit@debbugs.gnu.org; Sun, 15 Sep 2024 06:10:31 -0400 Original-Received: from mail-lj1-f172.google.com ([209.85.208.172]:50475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1splf8-00080v-KW for 73231@debbugs.gnu.org; Sun, 15 Sep 2024 05:35:24 -0400 Original-Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2f75f116d11so24712121fa.1 for <73231@debbugs.gnu.org>; Sun, 15 Sep 2024 02:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726392845; x=1726997645; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=s250JL5Z0iOqsAAROsDZQJMgMb2kUUx2lnR8TkIz3O8=; b=aiwz41KuTpW8z7pcEmSb78SfHl9ev+NDuUn8lCeY5x6EFBhQGF4myLrsfAf/KwTuMN rCE6kXx8XX9A332PaLDzLob1yIrkomWl/2OvUlb1/MvNtrBjzsv7XU6XBirI9gF9/bmZ v95ZkfMebi92OPwLPf/iT31meGOuGe/lGef5ndSfMj4rII4//Ato8jxsA9fP0UB91LrC uIZV2P8TfoezxDKCpUirmcboFO/SlRN3nGZmYq9ev6L9W38XCzlBs7ZUl/KN4csCZ5yC gTaMUdVwjQBq+ykVnoInXSgf39oCjPUc5TuknQT3K/OhwjcrbCfp6O+2ve2TpJ62AhVL +nNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726392845; x=1726997645; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=s250JL5Z0iOqsAAROsDZQJMgMb2kUUx2lnR8TkIz3O8=; b=HZAIvZQ6Sc8sfeAw3pAIHPzaKOtPJSNYsdFN4pkxmhaJp+o1o29pwIa8I43RnS7YsX 4b0MIr9W8ZTiZB7KDH/bMY36NG9mMMHT39HopyMd57OE9iMkxaV8IbR30eR7CVB0BaDN OPAihDNRftrxN50b2mWaadlmzKLU3jpt69cv6t+kA0JBtChYcDQ7j4vowWPXbNowXxKf Jtm7qs+mC222Wi7oimbI7eRbTPMmjMKT0dVt0SSN5+n6JX5rWv3QQ2RipwnlC28ebohD ldR7IVLhbHyoptgo7zT/14MEZfx0jh/KSW66wrzI/WTfYI+Y+S9tY8wxUxteD/W/WR62 r+Qg== X-Gm-Message-State: AOJu0Yy5Hs0/qafiT7gih/D8iT9Jv29jbivQ2Tfup2AiZeMaFWeLXSfT mC5WiXCRDu/VbLUNL2onieaA/l1zw67Q31n7mJ8vqAvdrkImtwikz1E4YQtEW8EUDkP4FKUitjH rLvVzHqkMRpfY9Bb6l3TRGuzLl09Pd1dHhnI= X-Google-Smtp-Source: AGHT+IG6NWF1txBr1PQykM3dz15TwwHSQLU/2sbOTQHzKsRR3DX/NBR5TXGomFxXz0jefujIfbz2tDcm9rc3GDs1DKo= X-Received: by 2002:a2e:be86:0:b0:2f7:543a:3b1a with SMTP id 38308e7fff4ca-2f7918e8430mr39993491fa.7.1726392844248; Sun, 15 Sep 2024 02:34:04 -0700 (PDT) In-Reply-To: <86bk0pe3z9.fsf@gnu.org> X-Mailman-Approved-At: Sun, 15 Sep 2024 06:10:26 -0400 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:291838 Archived-At: > >>> 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.