Received: (at 73231) by debbugs.gnu.org; 15 Sep 2024 10:10:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 15 06:10:31 2024 Received: from localhost ([127.0.0.1]:48464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1spmD8-0001Y1-Cr for submit <at> debbugs.gnu.org; Sun, 15 Sep 2024 06:10:31 -0400 Received: from mail-lj1-f172.google.com ([209.85.208.172]:50475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <misohena@HIDDEN>) id 1splf8-00080v-KW for 73231 <at> debbugs.gnu.org; Sun, 15 Sep 2024 05:35:24 -0400 Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2f75f116d11so24712121fa.1 for <73231 <at> 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) MIME-Version: 1.0 References: <861q1n1z2z.fsf@HIDDEN> <867cbfk0e5.fsf@HIDDEN> <CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN> <86v7yyiven.fsf@HIDDEN> <CAAo_Hv90GUbA7wm_v8gLGeRAULjmis27YLuFsBpGDFZVvi41JA@HIDDEN> <8634m2h3cq.fsf@HIDDEN> <CAAo_Hv9RxwwXNPUkMOfumJ2WTdBMxJ6bFQnYK_P6ucNnBv3YzA@HIDDEN> <86jzfde8o1.fsf@HIDDEN> <CAAo_Hv9Rm6drD0UkNFVr_R+Vwuk2jQZWW-3NdwxF9j60dCcZvw@HIDDEN> <86bk0pe3z9.fsf@HIDDEN> In-Reply-To: <86bk0pe3z9.fsf@HIDDEN> From: AKIYAMA Kouhei <misohena@HIDDEN> Date: Sun, 15 Sep 2024 18:33:52 +0900 Message-ID: <CAAo_Hv-ZtfYNX43bgJ2g-g82EK7G=MHvJYMbqd6tTSraHmGdQg@HIDDEN> Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all thumbnails are created (MS-Windows) To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 73231 X-Mailman-Approved-At: Sun, 15 Sep 2024 06:10:26 -0400 Cc: 73231 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > >>> 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.
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.
Received: (at 73231) by debbugs.gnu.org; 15 Sep 2024 10:10:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 15 06:10:28 2024
Received: from localhost ([127.0.0.1]:48458 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1spmD5-0001Xh-Uz
for submit <at> debbugs.gnu.org; Sun, 15 Sep 2024 06:10:28 -0400
Received: from mail-lj1-f170.google.com ([209.85.208.170]:55784)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <misohena@HIDDEN>) id 1spjlk-0001Cg-A4
for 73231 <at> debbugs.gnu.org; Sun, 15 Sep 2024 03:34:04 -0400
Received: by mail-lj1-f170.google.com with SMTP id
38308e7fff4ca-2f752d9ab62so22308581fa.3
for <73231 <at> debbugs.gnu.org>; Sun, 15 Sep 2024 00:33:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1726385567; x=1726990367; 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=+LRKNnH7/dIaAJ0mYkS2mWIoffoIuWZGw67BxeaQoCQ=;
b=iDCZcKO/eu5FQsPC7GzUOhthRJgrgkIYcsapHp7FbZXF7D+i6DKNqxu7aTLFbn+kAr
2+Ra7sUyQfZ/I7WSxIwXq42P8faDeT8Wd8AKD48GqM3Ar9IsOlpQTqyXHLs/NYdmh10J
to0LTr3Ag2bhWmlUOlPfoZyMrwm977BUtChj1h74+Z+aaQUpWapMRs6fmAUvAoJq/4BG
fobGxN3qPo3wXC0+8pPB3hTftPk+/gyJxmwkaGdMJlE6v7a/0zAa2c29x75xLI4QwC7G
olg6GNkygIAOKe5+1UHiK3crJXqmZyNY6U4nOXb8TqwpZWeAk44Q62reJjCvQyPC/MJC
M5Ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1726385567; x=1726990367;
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=+LRKNnH7/dIaAJ0mYkS2mWIoffoIuWZGw67BxeaQoCQ=;
b=TToYMSDOZwElIChMBs9AR3zprz9rrQGMFzhJEmhbheXzBt87XHoksVBPAjHiUlS5VX
niOFyhytmDf2W4ouwpOoEbHBn22ZVk9Ht/ZSoHDdQjYwvRYQsDh1ljolRRptF7390uo7
TUeCve2LkkagKfn/UnVaanbbGoEj25mKHs9/JiScorGekWyz9aUyTUpyTIaRH/9W5fqj
WF0xrPbFB5Qa2jPUaFch7hHDbiZVmt5Q4JbHv8Wq/Z6WJJH/dudSyrERsE9pZidS4QPf
Xi30o54WY+tKCETy1AkztGzJvfpvD60lKUoCY+DMiPA3yBvx9poKNhrDTS7h65aJ3uFf
S8xA==
X-Gm-Message-State: AOJu0Yy5EgNCWYMRG+w5alzo1SAl+EDAZg/yezT3N4EVzjahmg0mINF0
AEsYBGMD8SL/9yb3k0x1zSm5FG6hoLznwTXVOTaQ79xzM55ol/u1HXuUTWzfdnoxN3+LmA3EsCK
0cX/4w+6SB+J1DS8v28OAaJ9H9S8=
X-Google-Smtp-Source: AGHT+IHADfoUUoea2mk8qlqsQCZZ1zE9QABD4a3RrR/iFhOY5BMAXZGkpJVQTjsS+M3SmKyNqempUl3StLXABEULFLE=
X-Received: by 2002:a05:651c:b0f:b0:2f7:5914:c22e with SMTP id
38308e7fff4ca-2f7918e09e0mr38635491fa.6.1726385566050; Sun, 15 Sep 2024
00:32:46 -0700 (PDT)
MIME-Version: 1.0
References: <861q1n1z2z.fsf@HIDDEN> <867cbfk0e5.fsf@HIDDEN>
<CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN>
<86v7yyiven.fsf@HIDDEN>
<CAAo_Hv90GUbA7wm_v8gLGeRAULjmis27YLuFsBpGDFZVvi41JA@HIDDEN>
<8634m2h3cq.fsf@HIDDEN>
<CAAo_Hv9RxwwXNPUkMOfumJ2WTdBMxJ6bFQnYK_P6ucNnBv3YzA@HIDDEN>
<86jzfde8o1.fsf@HIDDEN>
In-Reply-To: <86jzfde8o1.fsf@HIDDEN>
From: AKIYAMA Kouhei <misohena@HIDDEN>
Date: Sun, 15 Sep 2024 16:32:34 +0900
Message-ID: <CAAo_Hv9Rm6drD0UkNFVr_R+Vwuk2jQZWW-3NdwxF9j60dCcZvw@HIDDEN>
Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all
thumbnails are created (MS-Windows)
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 73231
X-Mailman-Approved-At: Sun, 15 Sep 2024 06:10:26 -0400
Cc: 73231 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> > 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. If necessary, the user can change the settings of the
program that creates thumbnails by themselves (after installing
ImageMagick or GraphicsMagick). 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?
> > 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.
> > > > > 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.
Ah, sorry. That was a mistake on my part. The queue is definitely not
empty when queue-run is first called. Checking whether the queue is
empty would be meaningless unless it is done before the first job is
added to the queue. Or I need to use the approach you showed.
> 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.
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.Received: (at 73231) by debbugs.gnu.org; 15 Sep 2024 09:46:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 15 05:46:13 2024 Received: from localhost ([127.0.0.1]:48451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1splpd-0000DC-8G for submit <at> debbugs.gnu.org; Sun, 15 Sep 2024 05:46:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1splpb-0000Cx-LI for 73231 <at> debbugs.gnu.org; Sun, 15 Sep 2024 05:46:12 -0400 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 <eliz@HIDDEN>) id 1splpK-0001WY-K1; Sun, 15 Sep 2024 05:45:54 -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=INOnV2aRZEsEwYgPnh1IlR5YDO5jCTrAD9XTVDBuQe0=; b=TdHDwx0k7qKq jgR2cZkBDlGqsPVg+wLJXzkvNwXM365+mvTuphV31xdurL7wrIdo6UIFotIMfmFFjlqOeAAMEqJ5u JIQfCc1ZcTn27kvhZ45c5AReo8pU6uSZIHZlXGfoRsL/XbdH5Wjhv3HU3ZcQSTPdhPNLydp2ZTFOe 9x0XoEPiYvbgooDzqgMqUFeGqqfta8AN1X402mP5D4hmFnVyird8eq0WvLk11SbyvMD1fuSZ5Jlpb RIkWyt+L9XD6UqFufFz/L8EIo+jGuemQ3vdl2FJ0eIMNn79AANLPF6DuvT59qU9leruqU0arZD/X6 Dau/Fsne1YFV0nOPP4cNJA==; Date: Sun, 15 Sep 2024 12:45:51 +0300 Message-Id: <864j6hdzcg.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: AKIYAMA Kouhei <misohena@HIDDEN> In-Reply-To: <CAAo_Hv-ZtfYNX43bgJ2g-g82EK7G=MHvJYMbqd6tTSraHmGdQg@HIDDEN> (message from AKIYAMA Kouhei on Sun, 15 Sep 2024 18:33:52 +0900) Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all thumbnails are created (MS-Windows) References: <861q1n1z2z.fsf@HIDDEN> <867cbfk0e5.fsf@HIDDEN> <CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN> <86v7yyiven.fsf@HIDDEN> <CAAo_Hv90GUbA7wm_v8gLGeRAULjmis27YLuFsBpGDFZVvi41JA@HIDDEN> <8634m2h3cq.fsf@HIDDEN> <CAAo_Hv9RxwwXNPUkMOfumJ2WTdBMxJ6bFQnYK_P6ucNnBv3YzA@HIDDEN> <86jzfde8o1.fsf@HIDDEN> <CAAo_Hv9Rm6drD0UkNFVr_R+Vwuk2jQZWW-3NdwxF9j60dCcZvw@HIDDEN> <86bk0pe3z9.fsf@HIDDEN> <CAAo_Hv-ZtfYNX43bgJ2g-g82EK7G=MHvJYMbqd6tTSraHmGdQg@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73231 Cc: 73231 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: AKIYAMA Kouhei <misohena@HIDDEN> > Date: Sun, 15 Sep 2024 18:33:52 +0900 > Cc: 73231 <at> debbugs.gnu.org > > > 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? Yes, IMO. If GraphicsMagick is installed after the package is loaded by Emacs, the result will be incorrect. > > > 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? My point is that customizing the value is usually followed by saving the customizations, which will cause all the future Emacs session to use the same fixed value, bypassing the dynamic decision in the original value. > > > 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? It is used almost everywhere where some function can be provided either by an external program or by an internal Emacs API. > 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. Like I said, the main reason was technical: I wanted to make sure the test detects when 'convert' or 'gm' is installed, even if they are installed while the Emacs session is already running and it already loaded the image-dired package. > > 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? Maybe. We'll have to see when this becomes relevant. > 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. Thanks.
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.Received: (at 73231) by debbugs.gnu.org; 15 Sep 2024 08:06:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 15 04:06:07 2024 Received: from localhost ([127.0.0.1]:48264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1spkGk-00033A-WB for submit <at> debbugs.gnu.org; Sun, 15 Sep 2024 04:06:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1spkGj-00032R-JR for 73231 <at> debbugs.gnu.org; Sun, 15 Sep 2024 04:06:06 -0400 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 <eliz@HIDDEN>) 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==; Date: Sun, 15 Sep 2024 11:05:46 +0300 Message-Id: <86bk0pe3z9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: AKIYAMA Kouhei <misohena@HIDDEN> In-Reply-To: <CAAo_Hv9Rm6drD0UkNFVr_R+Vwuk2jQZWW-3NdwxF9j60dCcZvw@HIDDEN> (message from AKIYAMA Kouhei on Sun, 15 Sep 2024 16:32:34 +0900) Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all thumbnails are created (MS-Windows) References: <861q1n1z2z.fsf@HIDDEN> <867cbfk0e5.fsf@HIDDEN> <CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN> <86v7yyiven.fsf@HIDDEN> <CAAo_Hv90GUbA7wm_v8gLGeRAULjmis27YLuFsBpGDFZVvi41JA@HIDDEN> <8634m2h3cq.fsf@HIDDEN> <CAAo_Hv9RxwwXNPUkMOfumJ2WTdBMxJ6bFQnYK_P6ucNnBv3YzA@HIDDEN> <86jzfde8o1.fsf@HIDDEN> <CAAo_Hv9Rm6drD0UkNFVr_R+Vwuk2jQZWW-3NdwxF9j60dCcZvw@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73231 Cc: 73231 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: AKIYAMA Kouhei <misohena@HIDDEN> > Date: Sun, 15 Sep 2024 16:32:34 +0900 > Cc: 73231 <at> 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.
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.
Received: (at 73231) by debbugs.gnu.org; 15 Sep 2024 07:18:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 15 03:18:14 2024
Received: from localhost ([127.0.0.1]:48222 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1spjWP-0000K0-UQ
for submit <at> debbugs.gnu.org; Sun, 15 Sep 2024 03:18:14 -0400
Received: from mail-lj1-f181.google.com ([209.85.208.181]:47290)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <misohena@HIDDEN>) id 1spe2H-0005ZS-81
for 73231 <at> debbugs.gnu.org; Sat, 14 Sep 2024 21:26:46 -0400
Received: by mail-lj1-f181.google.com with SMTP id
38308e7fff4ca-2f74b6e1810so30184851fa.2
for <73231 <at> debbugs.gnu.org>; Sat, 14 Sep 2024 18:26:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1726363528; x=1726968328; 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=KX7PDtmAru7eUmSPho+mM1qA2CP+XDM+HOCp4hgBGuQ=;
b=E7er7qea1c/o2Ebe9l+rKNnYT8HLJ89KNKLrT5jSysjZrpb8AF2XGls0M3pbfIu/fh
oES30Bn/81MtCZmTW5PtcQl6fjhIKOcq6tqqLHxyaEx2XPOvJc79eqpxym+3GKGOzpcp
B3BW0w6EBuGZx5hK2UXkSe51i4LnCDK7PymeJo5inZRYDCJ3E5g3xn7DnkgRn4DZwnxM
OOCiFsBpN3lgXG3GzDS6mPd3VmvDsiMYX0K9zeZHFaAHWFT/LYIthnagp6r5h2wrMIut
UIPnnIY10LRLzalsWdQTYiwtpE8GIjKNW+chYQYz8VQ+HPf/sG8oiKdDnstKRlSpDXlL
VKzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1726363528; x=1726968328;
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=KX7PDtmAru7eUmSPho+mM1qA2CP+XDM+HOCp4hgBGuQ=;
b=SJYdagx8nOh9MPSXbrT+a2hdiQ2eWnTvwwVc3IepNePPkNQ3NZ7WsUY94y8gsuPM5F
8Rol4Czi8f7VY+LNKsCbS+kNH4IlgGUJHZqX2eWme961VfQaYU7bYuMHMej0luBJawI6
aBHM/rWE67xokTRW4pjW25SVTwaIh5g4AtjcieSrsWA7LEFHJHc93E/GadtWO83MhD2y
OpDQjxFRoYUNbtPBWlDy60VoxHII93mJGPMPRSMkQymdyTP4x9AcC0mAzeYVo9Yh5Nkp
AeY136pCR5dzpXigI/rMAo2UbuLXWCdXNTCHZRZqsyFtCCGbOww8qz7X1KpFA/6L+I19
nisQ==
X-Gm-Message-State: AOJu0YxPyYwH0RUupzOHfVYIwBVrnkMHrtLnXrlISpJIkU6lLSSE/FGV
R7BuU6iH/vZJnowAMIkLA06y8PWv5jxpoSYkmv8cDO+UQKxolL4aHIgt/PAM516a/58xx4UvxPw
221K0YLcDj8AbKu1Fa/UKRkfSC3SJsbwi4nA=
X-Google-Smtp-Source: AGHT+IESh8zdbIp+AucqmV9eqzEMk4Iz3vwwkRr7hPsMp3Blwo7Dmt5EtTnEtrF77wlDOJXijnCD7Yxhjursrc09ORI=
X-Received: by 2002:a2e:5149:0:b0:2f6:6074:db71 with SMTP id
38308e7fff4ca-2f787dbf822mr48860641fa.17.1726363527208; Sat, 14 Sep 2024
18:25:27 -0700 (PDT)
MIME-Version: 1.0
References: <861q1n1z2z.fsf@HIDDEN> <867cbfk0e5.fsf@HIDDEN>
<CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN>
<86v7yyiven.fsf@HIDDEN>
<CAAo_Hv90GUbA7wm_v8gLGeRAULjmis27YLuFsBpGDFZVvi41JA@HIDDEN>
<8634m2h3cq.fsf@HIDDEN>
In-Reply-To: <8634m2h3cq.fsf@HIDDEN>
From: AKIYAMA Kouhei <misohena@HIDDEN>
Date: Sun, 15 Sep 2024 10:25:15 +0900
Message-ID: <CAAo_Hv9RxwwXNPUkMOfumJ2WTdBMxJ6bFQnYK_P6ucNnBv3YzA@HIDDEN>
Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all
thumbnails are created (MS-Windows)
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 73231
X-Mailman-Approved-At: Sun, 15 Sep 2024 03:18:13 -0400
Cc: 73231 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
> > 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 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.
I agree that this doesn't look very good, and in this case, it's
already checked that it doesn't exist, so having to check again would
be inefficient.
> > >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.
> > 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.
That's probably true.
After all, is the default "convert" just for people who haven't
explicitly set image-dired-cmd-create-thumbnail-program and want to
keep using "convert"?
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")
(I don't know whether it's better to separate the variables.)
This way, even if convert is installed, users who want to try the
w32image-create-thumbnail function can explicitly select it.
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'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. Are you
talking about what happens when you move to another directory after
that? In that case, there are two situations: the queue is sometimes
empty and sometimes not. When it's empty, convert is checked
again. When it's not empty, it means the previous thumbnail creation
process is still ongoing. This is when the PC is working hard to
create thumbnails by starting many processes. It's hard to imagine
installing ImageMagick during that time. If you try to install it, as
I wrote before, with the current implementation, there is a
possibility that the installation process and the execution of
convert.exe will overlap (for example, if convert.exe is installed but
the necessary dll is not yet installed, it may be determined that
convert can be used, but image conversion may result in an
error). Even if the switch is successful, the quality of the
thumbnails will change at an unexpected point in time. I thought it
would be better to switch when the queue is empty than the current
implementation.
> > 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...
Well, this seems to be a better idea. Of course, all timing must be
considered. It takes more effort to implement than the above idea in
many ways, so I'm not sure if it's okay, but if you don't mind. I
guess the queue will also contain information about which command to
execute.
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.
Received: (at 73231) by debbugs.gnu.org; 15 Sep 2024 06:24:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Sep 15 02:24:58 2024
Received: from localhost ([127.0.0.1]:48177 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1spigs-0005fK-9F
for submit <at> debbugs.gnu.org; Sun, 15 Sep 2024 02:24:58 -0400
Received: from eggs.gnu.org ([209.51.188.92]:33266)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1spigq-0005f4-Hg
for 73231 <at> debbugs.gnu.org; Sun, 15 Sep 2024 02:24:57 -0400
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 <eliz@HIDDEN>)
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==;
Date: Sun, 15 Sep 2024 09:24:30 +0300
Message-Id: <86jzfde8o1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: AKIYAMA Kouhei <misohena@HIDDEN>
In-Reply-To: <CAAo_Hv9RxwwXNPUkMOfumJ2WTdBMxJ6bFQnYK_P6ucNnBv3YzA@HIDDEN>
(message from AKIYAMA Kouhei on Sun, 15 Sep 2024 10:25:15 +0900)
Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all
thumbnails are created (MS-Windows)
References: <861q1n1z2z.fsf@HIDDEN> <867cbfk0e5.fsf@HIDDEN>
<CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN>
<86v7yyiven.fsf@HIDDEN>
<CAAo_Hv90GUbA7wm_v8gLGeRAULjmis27YLuFsBpGDFZVvi41JA@HIDDEN>
<8634m2h3cq.fsf@HIDDEN>
<CAAo_Hv9RxwwXNPUkMOfumJ2WTdBMxJ6bFQnYK_P6ucNnBv3YzA@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 73231
Cc: 73231 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: AKIYAMA Kouhei <misohena@HIDDEN>
> Date: Sun, 15 Sep 2024 10:25:15 +0900
> Cc: 73231 <at> 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.
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.
Received: (at 73231) by debbugs.gnu.org; 14 Sep 2024 14:11:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 14 10:11:57 2024
Received: from localhost ([127.0.0.1]:47460 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1spTVF-0000sJ-3E
for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 10:11:57 -0400
Received: from mail-lj1-f173.google.com ([209.85.208.173]:48379)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <misohena@HIDDEN>) id 1spQoP-0006x4-6X
for 73231 <at> debbugs.gnu.org; Sat, 14 Sep 2024 07:19:34 -0400
Received: by mail-lj1-f173.google.com with SMTP id
38308e7fff4ca-2f758f84dfbso25651341fa.0
for <73231 <at> debbugs.gnu.org>; Sat, 14 Sep 2024 04:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1726312697; x=1726917497; 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=reeR6MeRyj3u+RdjkNvrgtdlKHmnLBRpOrZAcBawOtk=;
b=dst/C4yci8VYrJzDml3UiHBREGVsZmZoPq4RglsTjMqXPBKzef9oiauaHt45GrBXGd
I7USpV5f8HiW5zcPEdLKObUBm5uNWBCCWOhagVY1m49/s2FhR2mUcRqRUSQp7CFmwvJr
pRbTxmRcPa6C9dVCH0AaN+CEY2TDsJC0n4q7fM+1YinCliE2AfvLmNKDCQdUA4RoIaWJ
1uun17aDNJ4wFUW+m7ZfOMYTWT6NkBtHRdjRSEzVQVfWQII+VeuuiJiY+/EiW3mknMde
ni4EKkHq+9XdU/i7NZmx3Li73hQl+3tmSns6V0IHCL//XsFzFuBlnQsF+W3oKWlCp/hC
hXdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1726312697; x=1726917497;
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=reeR6MeRyj3u+RdjkNvrgtdlKHmnLBRpOrZAcBawOtk=;
b=LomT2PplYveq0YR20IrJewOccyQwpRK9646/VE6iYf4PPMfR9tXj1Ft/wQ7QXF7Hzp
pDa1vKZ9FhtvZda7qjDkkzQfa4Wz7aEab/jnUEZCh4iwKJ0XzjMrRV243YftNBj/M26S
GIRc8vg63xpWTzg/ijKUrnsG3ZLGfro3SWzmF74+K6BS1tXQT1qSmc1LnLOiavzLDHFG
qVItXgCcRKbAClybwdrTYT18uXWSCQTrKERlOxZ5lOxzbtvsqxas0PcLB4klyTXvXNr7
gMdmvvSuTyosgHu6eS0qtn/QBEpZ3/iJSolA7m3cuXqz1WFi+ts+kZXIUFFaNeeRfVxv
J2VA==
X-Gm-Message-State: AOJu0YwaFJ5OEgBZiDcpxZLFryUPLYN/PeTEA17rBKv6Drd1UEvVXYjT
8GZ6aJHYNQY6j130YFOWpDZMPxVLXyCwp4CPXNSM7JVX87km4LDgSIJNcQepFO0grfRkJ8UWenq
0gNiDgC2U03pKpbKgzvJCU8F7IxM=
X-Google-Smtp-Source: AGHT+IFk8VEoddct7c2dci8wqFprSz9nFiJVUICp8qpYRsCxeqBe4mRjon56GkCsRXY6BqUJNrbST3EI9+/2REep+9E=
X-Received: by 2002:a2e:b8c2:0:b0:2f4:5d9:e8e3 with SMTP id
38308e7fff4ca-2f787dad4c0mr57576961fa.7.1726312695988; Sat, 14 Sep 2024
04:18:15 -0700 (PDT)
MIME-Version: 1.0
References: <861q1n1z2z.fsf@HIDDEN> <867cbfk0e5.fsf@HIDDEN>
<CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN>
<86v7yyiven.fsf@HIDDEN>
In-Reply-To: <86v7yyiven.fsf@HIDDEN>
From: AKIYAMA Kouhei <misohena@HIDDEN>
Date: Sat, 14 Sep 2024 20:18:04 +0900
Message-ID: <CAAo_Hv90GUbA7wm_v8gLGeRAULjmis27YLuFsBpGDFZVvi41JA@HIDDEN>
Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all
thumbnails are created (MS-Windows)
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 73231
X-Mailman-Approved-At: Sat, 14 Sep 2024 10:11:55 -0400
Cc: 73231 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Thank you for answering my question. I now understand better.
> 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?
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? I'm not familiar with the parts written in C, but would you be
hesitant to add one just for such a small purpose?
> 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?
Is a mechanism like jit-lock really necessary? I'm not sure of the
exact timing of when images added outside of the visible area are
loaded. Could there be any differences in image loading between using
image-clear-cache for reloading and changing the display property?
> > 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.
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?
> > 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?
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.
When you try to create multiple thumbnails at once (using
image-dired-show-all-from-dir or by marking and adding), many jobs
will accumulate in the image-dired-queue. It will only check the first
one.
You didn't say that users should be able to install ImageMagick while
Emacs is creating thumbnails, right? That would mean that the
installation process and the call to convert.exe could happen at the
same time, and there's no guarantee that convert.exe will work
correctly.
Skipping the test when only one thumbnail is being created doesn't
make much difference. The real issue arises when multiple thumbnails
are being created at once, causing the slow test process to be
repeated for each thumbnail. And testing for the existence of convert
and switching methods while creating many thumbnails is not only
wasteful but even harmful.
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.
> 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. Each OS
has its own way, and software placement is one of them. Separating
directories for each application is not something that is unique to
MS-Windows. Even Emacs Lisp can be used as needed to either put it in
a single lisp directory or to put it in a separate directory for each
package (come to think of it, Emacs's load-path also has some
troublesome points). However, since such a choice is possible, I do
not intend to interfere with it.
> > 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.
Understood, I respect your opinion. I will withdraw the idea of
testing only once at the first time.
--
# Longer paragraphs require more translation effort and less accuracy.
# If you don't understand the meaning, please let me know.
# In machine translation, "I" is often written as "you" or "we"!
AKIYAMA Kouhei
misohena@HIDDEN
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.
Received: (at 73231) by debbugs.gnu.org; 14 Sep 2024 11:39:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 14 07:39:07 2024
Received: from localhost ([127.0.0.1]:44965 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1spR7L-00085s-3i
for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 07:39:07 -0400
Received: from eggs.gnu.org ([209.51.188.92]:55464)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1spR7I-00085H-EJ
for 73231 <at> debbugs.gnu.org; Sat, 14 Sep 2024 07:39:05 -0400
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 <eliz@HIDDEN>)
id 1spR72-0005pe-IF; Sat, 14 Sep 2024 07:38: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=zwiX4DADNI7AT6DsqSLLAv6Iq9f67c58pF2yQdDvEkg=; b=Ih3JxTyZ23kQ
z/Qe5jC+Ta8YQ9Epfc65YFn59fMn2oKjCN9l81vZdjXfgxfE5KSF5OJDk5cPZVLFM/sQuWdVR7i7o
EWMLA3LUd4xkKo9wt4cusncK1ys/yH9qfEyuZxpKmeOjfogwJKOJXwNAd4d2Mf8PoDiBw2+17bXPq
EGfB/VvnIrJXqo2D6ncjcZlvI+QPaLPJ6G7hXb+pPBOI0vROvuAt616gTDSIc6HQdCSlbwy3K2lCB
KJf0Z/Aya+VscVySz3fmwdOwpgLP9Qd1sP8b3tgqA170Dk1Wz67dn+tcpBQ9kb4q/100Qf4/ZDECe
8LgDzAgb5Jmih/jcVmnlYA==;
Date: Sat, 14 Sep 2024 14:38:45 +0300
Message-Id: <8634m2h3cq.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: AKIYAMA Kouhei <misohena@HIDDEN>
In-Reply-To: <CAAo_Hv90GUbA7wm_v8gLGeRAULjmis27YLuFsBpGDFZVvi41JA@HIDDEN>
(message from AKIYAMA Kouhei on Sat, 14 Sep 2024 20:18:04 +0900)
Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all
thumbnails are created (MS-Windows)
References: <861q1n1z2z.fsf@HIDDEN> <867cbfk0e5.fsf@HIDDEN>
<CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN>
<86v7yyiven.fsf@HIDDEN>
<CAAo_Hv90GUbA7wm_v8gLGeRAULjmis27YLuFsBpGDFZVvi41JA@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 73231
Cc: 73231 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: AKIYAMA Kouhei <misohena@HIDDEN>
> Date: Sat, 14 Sep 2024 20:18:04 +0900
> Cc: 73231 <at> 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.
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.Received: (at 73231) by debbugs.gnu.org; 14 Sep 2024 06:59:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 14 02:59:20 2024 Received: from localhost ([127.0.0.1]:44580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1spMkZ-0000dK-Sq for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 02:59:20 -0400 Received: from mail-lj1-f182.google.com ([209.85.208.182]:61707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <misohena@HIDDEN>) id 1spGcZ-0003x2-2h for 73231 <at> debbugs.gnu.org; Fri, 13 Sep 2024 20:26:39 -0400 Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2f754d4a6e4so31744341fa.3 for <73231 <at> debbugs.gnu.org>; Fri, 13 Sep 2024 17:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726273523; x=1726878323; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BHIM07oo4UGMbdN3TVynjdG5y8G4oU/LNmkDTmPCD6w=; b=HE0JLO33EzgZFKMY+axk4jQEJG/Gv4qpCXQTl76Dp3+bOegwTCo/5dFP5J0O1Taoi1 qyZjCQ5KaUCzJcvSht6l1CRn1dSoXgJpYVP/utjMMClhRFUQ/NT2wve5ya2bjirEurY2 RICUHHBinhtT+ARztWbPM1pB8N3Zgy4EH5AsBVRtBT8UtJvMkGdLKzFaSvilnlHKLJN5 3n5SySw136gzZHhyRSs/QqC+v/gPpF/6t8zKYr4/qDbYWFnU9A/gydh8hUWb8C52D6U0 ycttvLWcf5x9nm2doV83jvfHf8s1OmCZim1CB3fCrHwbm8N0kFWX6e8vzDixnYlLxuzu mvYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726273523; x=1726878323; h=content-transfer-encoding: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=BHIM07oo4UGMbdN3TVynjdG5y8G4oU/LNmkDTmPCD6w=; b=sJ2R4CA1/Sx8+R6neyuEazdZATNMOpvz76b4LF5hM30YPrYBNFZCDdWg+u5VV77vEq loofSOH7t1OnB0Fuob0ctHjJPjlyzBfd5pYvhu+vWqEsXQCAM4u3xoBsxXkNb+omTA0T ZeQzOD0yDsOQ6+hH3g7t4tfhxX23PKxBvtwmhZRlC391n/+vBoKdQQNWYaelYYPW+f7V sLTgvSMMPvqVu5GdBro5vZes9HfA8whm35qtmsT7njWVHUX6C1VfrZRrKJojrpqg9MzU s+QG9I4TRKkyyGW5X5MUtbLtdta/sV/gamDtbl157mJgIoATnZqLTqRKtWJBpdqiZLjX 82Bw== X-Gm-Message-State: AOJu0YyO9ihtDKPmGfC7Av3IJc/ZfH/cwY0pYBW7/oTyeuqXwY6MtwxL AR+aMQCgiLSwioO/0d1oku0mKzXqEcakSSB7M9vv9LNWT2VEXBypdMJyZXremd8zUMIaixO7b1O Abh51G+C+Hndgm3CG8A63RFX0MMA= X-Google-Smtp-Source: AGHT+IEJ4BjLryiR2r+5DJ4wgtoF3F6P4kP6zqkMATAfFXm33VecCcABelv1n2jfTIUxXnlvi4F7iAvRAZS6nPZWffo= X-Received: by 2002:a2e:be86:0:b0:2f7:5915:436e with SMTP id 38308e7fff4ca-2f787dad425mr47362931fa.2.1726273522893; Fri, 13 Sep 2024 17:25:22 -0700 (PDT) MIME-Version: 1.0 References: <861q1n1z2z.fsf@HIDDEN> <867cbfk0e5.fsf@HIDDEN> In-Reply-To: <867cbfk0e5.fsf@HIDDEN> From: AKIYAMA Kouhei <misohena@HIDDEN> Date: Sat, 14 Sep 2024 09:25:11 +0900 Message-ID: <CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN> Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all thumbnails are created (MS-Windows) To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 73231 X-Mailman-Approved-At: Sat, 14 Sep 2024 02:59:17 -0400 Cc: 73231 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Thank you for your response. # I forgot to CC it so I'll resend it. Sorry. The error message you are referring to is "Unable to load image (image :type jpeg ...)," correct? 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? Do you believe it would be better to change to synchronous processing and suppress the error message even when using ImageMagick? 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? If we fix that, it might be possible to suppress the error message even in asynchronous processing. 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. 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.) Honestly, I believe a single check at startup should be sufficient. Even if ImageMagick (with legacy utilities) is installed while Emacs is running, it won=E2=80=99t be accessible unless the PATH environment variable is updated. In the end, restarting Emacs is the quickest solution. Of course, this is a different story if there is already a directory (e.g., MSYS2 or Cygwin=E2=80=99s bin) prioritized over System32 in your PATH, where you can place convert.exe (for safety, I have MSYS2's bin placed after System32). -- # This report was created using machine translation. AKIYAMA Kouhei misohena@HIDDEN
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.
Received: (at 73231) by debbugs.gnu.org; 14 Sep 2024 06:47:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 14 02:47:50 2024
Received: from localhost ([127.0.0.1]:44561 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1spMZS-0008QH-0n
for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 02:47:50 -0400
Received: from eggs.gnu.org ([209.51.188.92]:60730)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1spMZQ-0008Q2-CI
for 73231 <at> debbugs.gnu.org; Sat, 14 Sep 2024 02:47:49 -0400
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 <eliz@HIDDEN>)
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==;
Date: Sat, 14 Sep 2024 09:47:28 +0300
Message-Id: <86v7yyiven.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: AKIYAMA Kouhei <misohena@HIDDEN>
In-Reply-To: <CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN>
(message from AKIYAMA Kouhei on Sat, 14 Sep 2024 09:25:11 +0900)
Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all
thumbnails are created (MS-Windows)
References: <861q1n1z2z.fsf@HIDDEN> <867cbfk0e5.fsf@HIDDEN>
<CAAo_Hv8iQ+jGGiJFKi5GgSH69mHCQ-90U7yr6T6Ri7sYMr0Jqw@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 73231
Cc: 73231 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: AKIYAMA Kouhei <misohena@HIDDEN>
> Date: Sat, 14 Sep 2024 09:25:11 +0900
> Cc: 73231 <at> 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.
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.Received: (at 73231) by debbugs.gnu.org; 13 Sep 2024 16:02:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 13 12:02:31 2024 Received: from localhost ([127.0.0.1]:44121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sp8kg-00088f-TR for submit <at> debbugs.gnu.org; Fri, 13 Sep 2024 12:02:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sp8kf-00088G-4x for 73231 <at> debbugs.gnu.org; Fri, 13 Sep 2024 12:02:29 -0400 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 <eliz@HIDDEN>) id 1sp8kQ-00054H-5l; Fri, 13 Sep 2024 12:02:14 -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=Uhcsm/PmFXYGpPT9HFaaHMRMWwI2Tn7q+J8QUX2/e0M=; b=RjRQfwJukNds cqVjfvdwV/1l21898dWebeCon5YJYSGtEOBsUKSvz1flfTcva6dTF6qHDgSoExp3vMfrexZ+jjwgb vIpHQZ6KMr82nJHP4o5wXWMFgq630Gqppo+v8wLyTW3jZPPzhvt5YJeQ68zOIk0WMht2/iHMgxD0U nowbnG6u1rrDLCrf1QumU7P51wMTFrEMVmUjCOctq2OcRysIHtbqL4+Bc7el+aZG0HAuZiLxXO0bo BEhJn2OOpNwfleWqRB/5polCA7Z3xfnpuWSV1DAcgKLFtd/dRBUWAH5yQ2t7NsxRy/ID7R+0bl5YE MERtGeVAsXilGsdFZknJDQ==; Date: Fri, 13 Sep 2024 19:02:10 +0300 Message-Id: <867cbfk0e5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: AKIYAMA Kouhei <misohena@HIDDEN> In-Reply-To: <861q1n1z2z.fsf@HIDDEN> (message from AKIYAMA Kouhei on Fri, 13 Sep 2024 22:07:48 +0900) Subject: Re: bug#73231: 30.0.91; image-dired cannot be operated until all thumbnails are created (MS-Windows) References: <861q1n1z2z.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73231 Cc: 73231 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: AKIYAMA Kouhei <misohena@HIDDEN> > Date: Fri, 13 Sep 2024 22:07:48 +0900 > > When using image-dired without ImageMagick or GraphicsMagick > available, operations could not be performed until all thumbnails had > been created. Thank you for your report and the research that went into it. When you speed up the display of the buffer, don't you see in *Messages* error messages about missing files that cannot be displayed? The default values of delays and timers were chosen so as to minimize these error messages for some reasonable amounts of images in a directory (your 274 images is way larger than what I had in mind). image-dired--probe-thumbnail-cmd is called frequently because the user could install ImageMagick at some point, and I didn't feel like adding complicated logic to allow detection of that that is cheaper. But if you have practical suggestions for how to make these tests more seldom without disabling them completely, that could be a good improvement. In general, the non-ImageMagick implementation was intended to be a fallback, for those who cannot or will not install ImageMagick. It is deliberately synchronous, but I think it performs well enough to be usable. Granted, improvements to the code are welcome, but if they make the redisplay error messages appear in more cases, I think such a change would be for the worse, because users can rightfully think Emacs has a bug.
bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 13 Sep 2024 15:29:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 13 11:29:04 2024
Received: from localhost ([127.0.0.1]:44032 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sp8EJ-0005uJ-EN
for submit <at> debbugs.gnu.org; Fri, 13 Sep 2024 11:29:04 -0400
Received: from lists.gnu.org ([209.51.188.17]:54892)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <misohena@HIDDEN>) id 1sp61v-00052a-8b
for submit <at> debbugs.gnu.org; Fri, 13 Sep 2024 09:08:07 -0400
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 <misohena@HIDDEN>)
id 1sp61l-00030w-SZ
for bug-gnu-emacs@HIDDEN; Fri, 13 Sep 2024 09:07:57 -0400
Received: from mail-pf1-x431.google.com ([2607:f8b0:4864:20::431])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <misohena@HIDDEN>)
id 1sp61j-0000ep-R3
for bug-gnu-emacs@HIDDEN; Fri, 13 Sep 2024 09:07:57 -0400
Received: by mail-pf1-x431.google.com with SMTP id
d2e1a72fcca58-7191901abd6so655099b3a.3
for <bug-gnu-emacs@HIDDEN>; Fri, 13 Sep 2024 06:07:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1726232873; x=1726837673; darn=gnu.org;
h=mime-version:message-id:date:subject:to:from:from:to:cc:subject
:date:message-id:reply-to;
bh=uF4/Ih0Cicp7GOITG9d+J8rVN7hBRUaK3iYIeRUuaGE=;
b=Myg8zD1LomAckcqsIVJwKRLJFMM5tj3ntanZ2Gnl4XQBGbIzuqq3AWU7gIkDZ+5GSt
hTEMu/JrTtoIUNmLzjimPVUZRbpdzOsU/rdrcpf2WTzqkJPoYFEweFjgDfGkM4Ci9kgI
/YpG+D8rEnYy/bYIDJA9bD7tzk1gEjp8X/V1I2ECB4yQsEHSos0reWZ+nemsIxVrcYU1
W3qJS6CbXI6MBwGVxEsLZT/jVAlewAWKzjmw/I4eOi7a646U8Lraw5u8i5Kgo6jzepFJ
LypWA51ol5U18BsIQjwc8cGouGFewHDs9JgYA88HNovG0CS8rKWxkiTcLqPA8UTPid2F
bLjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1726232873; x=1726837673;
h=mime-version:message-id:date:subject:to:from:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=uF4/Ih0Cicp7GOITG9d+J8rVN7hBRUaK3iYIeRUuaGE=;
b=NvcHj+aXF0b3Bowu4Rtw6cMDVwXKQE3xFr+UmZWeaRJkjZ/fwkxXTXYj6BWJACAmOr
agJi5PGw2bxnRlBBaNdAQfE66yQ22X+BDS4aik0j8chY7LrFcjUger6tYq5nnRokN/t6
1DUNzkke8hiXwgGmtsd8NNtsDZWwy0ALeu5WUoGCouOvv7zkg3KyXKa3kpssmDuFMSRf
+k9hFUEt1S32+N+/XQ9BDH93CBHcHGar/D1Ll0byNASH4FBlLFj5kDSEn/1XvixPw0as
O0SIrOhSsU+dClwSH16iWggoEHKnTJRBnaCZmMy9tBTmjPqe5bGcGVb8sYodnwC3Sv6g
NifA==
X-Gm-Message-State: AOJu0YxkUoxk46MGoBIoaGj6IWVYALCjJYHyBB79fLAdBsgG/VQTnNUk
TADWjNhrlgj7V0GgS2vG0r3StC2KKLlwFLn0IgzrP/gasjw7rgJgOIc2RA==
X-Google-Smtp-Source: AGHT+IEE4uu9Vms17N40kU5lkt+IB7qV5yShVerHZWpLXbTJYFp6UpGZ0yY5t0MYbtWlhRjX46sytw==
X-Received: by 2002:a05:6a00:c89:b0:70a:fb91:66d7 with SMTP id
d2e1a72fcca58-71936afab6cmr4192092b3a.20.1726232872430;
Fri, 13 Sep 2024 06:07:52 -0700 (PDT)
Received: from YAMABUKI (pl934.ag1212.nttpc.ne.jp. [61.197.25.166])
by smtp.gmail.com with ESMTPSA id
d2e1a72fcca58-719090ad8d7sm6052716b3a.160.2024.09.13.06.07.51
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 13 Sep 2024 06:07:51 -0700 (PDT)
From: AKIYAMA Kouhei <misohena@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 30.0.91; image-dired cannot be operated until all thumbnails are
created (MS-Windows)
X-Debbugs-Cc:
Date: Fri, 13 Sep 2024 22:07:48 +0900
Message-ID: <861q1n1z2z.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2607:f8b0:4864:20::431;
envelope-from=misohena@HIDDEN; helo=mail-pf1-x431.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Fri, 13 Sep 2024 11:29:01 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
When using image-dired without ImageMagick or GraphicsMagick
available, operations could not be performed until all thumbnails had
been created.
* Steps to reproduce
1. Open a command prompt (cmd.exe)
2. wget https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-30/emacs-30.0.91.zip
3. unzip emacs-30.0.91.zip
4. set PATH=c:\Windows\system32
(Make sure ImageMagick is not included)
5. .\bin\emacs -Q --init-directory=%CD%\.emacs.d
(Start with a brand new .emacs.d)
6. C-x C-f <my photo directory> RET
(<my photo directory> contains 247 jpg files)
7. M-x image-dired RET RET
8. After 36 seconds, the *image-dired* buffer is open with all
thumbnails converted.
(The aspect ratio of the image will be ignored and it will not be
rotated correctly, but that's a separate issue.)
Let me compare it with my previous setup. I'm using MSYS2's magick.exe.
9. C-x C-c
(exit emacs)
10. rmdir /S .emacs.d
(Remove thumbnails)
11. .\bin\emacs -Q --init-directory=%CD%\.emacs.d
12. (setq image-dired-cmd-create-thumbnail-program
"c:/msys64/ucrt64/bin/magick.exe"
image-dired-cmd-create-thumbnail-options
'("convert" "-auto-orient" "-define" "jpeg:size=%wx%h" "-size" "%wx%h"
"%f[0]" "-resize" "%wx%h>" "-strip" "jpeg:%t"))
13. C-x C-f <my photo directory> RET
14. M-x image-dired RET RET
15. After 5 seconds the *image-dired* buffer is opened. Only the first
few thumbnails have been converted.
16. After 19 seconds (from start) all thumbnails have been converted
and displayed.
* Cause:
The cause is the image-dired-thumb-queue-run function and the
image-dired-create-thumb function that calls it.
The image-dired-create-thumb function executes
image-dired-thumb-queue-run with a delay using (run-at-time 0 nil
#'image-dired-thumb-queue-run). Later, image-dired-thumb-queue-run is
called all at once in succession.
In the latter half of the image-dired-thumb-queue-run function,
image-dired-create-thumb-2 is executed with a delay using
(run-with-timer 0.05 nil #'image-dired-create-thumb-2 orig-file
thumb-file). There is no limit to the number of timers, so a new timer
is added even if one has already been scheduled. Therefore, all
thumbnails are created continuously and without interruption. The
number of seconds, 0.05, is not very meaningful.
(I apologize if these behaviors were intended)
* Solution:
You can achieve a similar behavior by limiting the number of images
when using the image-dired-create-thumb-2 function.
I tried modifying the latter half of the image-dired-thumb-queue-run
function as follows and tested it again.
;; We are on MS-Windows with ImageMagick/GraphicsMagick, and need to
;; generate thumbnails by our lonesome selves.
(while (and image-dired-queue
(< image-dired-queue-active-jobs 1))
(cl-incf image-dired-queue-active-jobs)
(let* ((job (pop image-dired-queue))
(orig-file (car job))
(thumb-file (cadr job)))
(run-with-timer 0.00 nil
(lambda (a b)
(cl-decf image-dired-queue-active-jobs)
(image-dired-create-thumb-2 a b))
orig-file thumb-file)))
As a result, the *image-dired* buffer appeared after 17 seconds, and
all thumbnails were created after 34 seconds.
The performance has dropped, but this is because
image-dired--probe-thumbnail-cmd is slow. So I set it as follows to
avoid matching "convert", and avoided the slow check process.
(setq image-dired-cmd-create-thumbnail-program "")
I tested it again, and the *image-dired* buffer appeared after 5
seconds, and all thumbnails were created after 7 seconds. This was
faster than when I used the magick command (despite running it in
multiple processes), and I got very good results. I think it's better
not to call image-dired--probe-thumbnail-cmd too frequently.
Recently, I have been increasingly using image-dired for organizing my
photos. I look forward to seeing how image-dired continues to
evolve. Thank you.
-------
In GNU Emacs 30.0.91 (build 2, x86_64-w64-mingw32) of 2024-09-12 built
on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.19045.4894)
Configured using:
'configure --with-modules --without-dbus --with-native-compilation=aot
--without-compress-install --with-tree-sitter
--enable-checking=yes,glyphs 'CFLAGS=-O0 -g3''
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
(NATIVE_COMP present but libgccjit not available)
Important settings:
value of $LANG: ja_JP.CP932
locale-coding-system: cp932
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort emacsbug mail-extr message sendmail mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
cl-loaddefs cl-lib japan-util rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process
native-compile emacs)
Memory information:
((conses 16 58721 16525) (symbols 48 6296 1) (strings 32 17245 3277)
(string-bytes 1 453015) (vectors 16 10080)
(vector-slots 8 252453 22466) (floats 8 32 648)
(intervals 56 1127 635) (buffers 992 11))
--
# This report was created using machine translation.
AKIYAMA Kouhei
misohena@HIDDEN
AKIYAMA Kouhei <misohena@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#73231; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.