From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: AKIYAMA Kouhei Newsgroups: gmane.emacs.bugs Subject: bug#73231: 30.0.91; image-dired cannot be operated until all thumbnails are created (MS-Windows) Date: Sat, 14 Sep 2024 20:18:04 +0900 Message-ID: References: <861q1n1z2z.fsf@gmail.com> <867cbfk0e5.fsf@gnu.org> <86v7yyiven.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12076"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73231@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 14 16:12:07 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1spTVP-0002zd-D3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Sep 2024 16:12:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spTVG-0006Ih-UY; Sat, 14 Sep 2024 10:11:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1spTVC-0006Hr-NP for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2024 10:11:55 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1spTVB-0001CK-Hp for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2024 10:11:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=reeR6MeRyj3u+RdjkNvrgtdlKHmnLBRpOrZAcBawOtk=; b=GDvv71Q4wi2Bd6qikZ04zFKJsWWtk0NUi0ZTS5mMVt3ii+OImcbPpJs5zlKLVxB+7qq/4CkYKnsoHJdN91eZIAgepW8tAKWrukqvN/XnAyP00ptig69ronjxsNIjCIP14U+IWEJKbIdpCETFq8rDe5Gf1oPJNZVmb+pRXsAfLyS2krZE2pdqgQ0noDGM4X1il5fywhIkceYulZMWFqLpTycJBda25yKtbczDmvHB0LmrWksvT6Ylj1aCdnfOSNqnTRkF9xh3POudUXsq+PPk6b2WNLIHPNlgeAlxUW0Dax+BewQ7KUSvKjzUxXgUnKV9dfPHnUN7nnPKpL58wkpRcw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1spTVM-0000tq-3G for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2024 10:12:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: AKIYAMA Kouhei Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2024 14:12:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73231 X-GNU-PR-Package: emacs Original-Received: via spool by 73231-submit@debbugs.gnu.org id=B73231.17263231173373 (code B ref 73231); Sat, 14 Sep 2024 14:12:04 +0000 Original-Received: (at 73231) by debbugs.gnu.org; 14 Sep 2024 14:11:57 +0000 Original-Received: from localhost ([127.0.0.1]:47460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spTVF-0000sJ-3E for submit@debbugs.gnu.org; Sat, 14 Sep 2024 10:11:57 -0400 Original-Received: from mail-lj1-f173.google.com ([209.85.208.173]:48379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1spQoP-0006x4-6X for 73231@debbugs.gnu.org; Sat, 14 Sep 2024 07:19:34 -0400 Original-Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2f758f84dfbso25651341fa.0 for <73231@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) In-Reply-To: <86v7yyiven.fsf@gnu.org> X-Mailman-Approved-At: Sat, 14 Sep 2024 10:11:55 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:291758 Archived-At: 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@gmail.com