From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id WDmPEblV3WY1OQAA62LTzQ:P1 (envelope-from ) for ; Sun, 08 Sep 2024 07:43:53 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id WDmPEblV3WY1OQAA62LTzQ (envelope-from ) for ; Sun, 08 Sep 2024 09:43:53 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=UdEjzc8m; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1725781433; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=NR261CXxOrUAK1R6atmtT+kw7h3JyuVV0tNgMfU4sTg=; b=oCs58yAv3zRtAAPET05e99nXiUkNwFHa/PxSZrSVzavjGP52YQKNEb63eKecUrbAFNgknX Hx0IUEtUVFAZecO8U+xV9yXYpx/KB3zae7DCazBsjIGTu9mCpjvl5YUkZi1trC/6OLor1Z 2X9bsna4Zi3kA9Je17VcoKA2gWxFKYjUf6OJjxGQbs2nka/uk5T1MdObGi+MYZQ43gC//D X+Upuxk5yjUVXeFwrq6YJu/rdllzy32CMAPn5gJbqQMofNfDwBZj+QyyaFS0ZbHHWOk+6J cR6BYIpkcAMfPwcAhZ4TIPBEVSUY6b2a16OuFqBzB/jpONx3jSRac9PPR2X0Tw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=UdEjzc8m; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1725781433; a=rsa-sha256; cv=none; b=fLLLOLW+N/0GmzIhvt5TbQ66Q6LeVbvTyPc1Jsncfh2NQtgZGaELtRrHDsYynr/1ladaB2 L5tcK1Ry4OfZnrMiLNeDdGWsJMGwo80xbMtRTEt/knsJnHkIj8Aw23NZYEyzAf/xXwtMsF apIinJJxOskZpW2eHt0FM1APVSjo6zubrAAYGrmNRMuYx8+Rcn1N3z9Z08xT6OGqj0Ey3g ycEmWRDFrrN1qNWg24usaAZjmq4E/sHDqv8BRYfuiQ/G0cuELgK8V7GiVX5N/+sU9Hm/Ep M57CZGsR5Rexw2ctYbX66+lajzdzeFKYRJNtY1j1KZ9PJctiGVgjMxDugy+m0g== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9153AA9DE for ; Sun, 08 Sep 2024 09:43:52 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1snCZN-0008WI-Fx; Sun, 08 Sep 2024 03:42:49 -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 ) id 1snCZK-0008Vp-LS for emacs-orgmode@gnu.org; Sun, 08 Sep 2024 03:42:46 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1snCZF-0002gO-VK for emacs-orgmode@gnu.org; Sun, 08 Sep 2024 03:42:44 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id F28CD240101 for ; Sun, 8 Sep 2024 09:42:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1725781350; bh=d3Jo5QnoxKzQ/kIXcPF8m2ckchx+DsU+S6NiZQpPJuI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=UdEjzc8mezoWbdhuRuITkHPnE2fUKZHtdIEQ8gA0Edo+fhe1McgHpftY/OtvCTH7L 7odW/tQs9mApG3jO6RztAZ1eNThHBKTMRyeYExRx4w9MD5XFlOHaOzPt0/oSzcyLG1 Hr2HRHxh7Olr3CIKDM20t0rgN7aQSQjzAH1QBnY5zBEs4Ha++8vHXNqne2nkLYKfz0 EdRUNtvaUAcROa/ddGlD7twub2bPouRTP2r9yLnLw1gxBzxf+YhXkcJCgmzU6YFK4i Tfyjkaev+/l0VAXPl2q24kU8agNnhazzP974dWeZqBRWOSsEIuumMTwWTsG/vvAlvs /klsigN7irKxQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4X1hkr5TtCz6txh; Sun, 8 Sep 2024 09:42:28 +0200 (CEST) From: Ihor Radchenko To: Karthik Chikmagalur Cc: stardiviner , Org mode Subject: Re: [PATCH v3] Inline image display as part of a new org-link-preview system In-Reply-To: <878qw9ak6a.fsf@gmail.com> References: <6461a84b.a70a0220.b6d36.5d00@mx.google.com> <64cc9b8a.170a0220.dfa99.2e18@mx.google.com> <87msz7kym0.fsf@localhost> <669882e5.050a0220.8ff6d.33c6@mx.google.com> <871q3logb9.fsf@localhost> <66a8b73b.170a0220.383476.996e@mx.google.com> <87o75yhwnu.fsf@localhost> <87v7zyyvm3.fsf@localhost> <87frr07xz8.fsf@gmail.com> <87cym38aj8.fsf@gmail.com> <87r0ajawgj.fsf@localhost> <87a5h77zb1.fsf@gmail.com> <87msl4wv8d.fsf@localhost> <875xrqg6cb.fsf@gmail.com> <874j70n559.fsf@localhost> <87msksabld.fsf@gmail.com> <87jzfwljkq.fsf@localhost> <87h6b09v4o.fsf@gmail.com> <878qwb8qw1.fsf@localhost> <878qw9ak6a.fsf@gmail.com> Date: Sun, 08 Sep 2024 07:43:52 +0000 Message-ID: <87o74ypp3b.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 9153AA9DE X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -9.71 X-Spam-Score: -9.71 X-TUID: Ui0FlVj+Wxfo Karthik Chikmagalur writes: >>> +BEG and END define the considered part. They default to the >>> +buffer boundaries with possible narrowing." >>> + (interactive "P") >>> + (when (display-graphic-p) >> >> Do we need it here? You check graphics both here and later in the >> preview function. We may probably drop the check herein. > > I moved the `refresh' clause out of the display-graphic-p check, but I > think it's needed. Otherwise this line will run once per previewed > image instead of once per call to `org-link-preview': > > (when (fboundp 'clear-image-cache) (clear-image-cache)) > > clearing newly placed previews (within the same run) from the cache. Sorry, I was not clear. I only referred to `display-graphic-p' check. I did not mean `clear-image-cache'. > That said, I have a question about `clear-image-cache' here. Why does > Org clear the Emacs frame's entire image cache every time > `org-link-preview-region' (or the previous `org-display-inline-images') > is called? This seems overreaching. There are many situations even > within Org mode where we want to avoid the extra file access that > clearing the image cache will cause, like in a buffer with hundreds of > LaTeX previews. Images in unrelated buffers/major-modes are also > affected. Here is the original code: (when refresh (org-remove-inline-images beg end) (when (fboundp 'clear-image-cache) (clear-image-cache))) Image cache is cleared _only_ with REFRESH argument. I think that makes sense, right? >>> + (let* ((width (org-display-inline-image--width link)) >>> + (align (org-image--align link)) >>> + (image (org--create-inline-image file width))) >> >> I am wondering why you left these functions in org.el. Why not moving >> them here? > > They seemed out of place in ol.el, so my plan was the following: > 1. This patch: Implement org-link-preview. > 2. Another patch: Move image creation/manipulation/geometry functions > from org into an org-image (or org-image-utils) library. Require it in > ol. > > However, I can move them wherever you want, let me know. I'd rather see them moved. You can later send another patch moving them into the new utils library, if you want. I am asking because you may or may not have time to create that followup patch. So, better have things sorted out at every step rather than relying upon followups that may or may not happen (e.g. for reasons you cannot control) >>> + (when image ; Add image to overlay >>> ... >>> + (overlay-put ov 'org-image-overlay t) >> >> This is redundant, isn't it? > > I don't know how create-image can fail. Suppose a .jpg file exists but > is corrupted or does not have image/jpeg data. Then create-image > returns nil, as does `org--create-inline-image'. This check guards > against trying to preview an "image" that's nil. Let me elaborate. In `org-link-preview-region', you set org-image-overlay property: + (overlay-put ov 'org-image-overlay t) + (overlay-put ov 'modification-hooks + (list 'org-link-preview--remove-overlay)) + ;; call preview function for link type + (if (funcall preview-func ov path link) + (when (overlay-buffer ov) Then, you do it yet again in `org-link-preview-file', when the property is already there - this part is redundant. I do not see how `org--create-inline-image' affects the above. >>> + (when (boundp 'image-map) >> >> What if not bound? Why not simply (require 'image)? > > Just unmodified old code. I've require'd image in ol now, let me know > if I should do it differently. Let's not require it on top level. Maybe better do it within the preview function. >> I am wondering whether asynchronicity should be implemented on high >> level rather than inside individual link preview functions. >> We may, for example, first create the necessary overlays and indicate >> that they are "processing..." first, and then call the actual preview >> functions asynchronously. >> >> If we leave asynchronous handling to individual previews, they will have >> no way to handle queuing large number of link previews, and we may arrive >> at the common situation with network processes when they schedule and >> finish around the same time, hanging Emacs while it is handling >> a bunch of process sentinels. > > I'm not sure how to solve this problem. Here's what I'm picturing -- > note that this doesn't actually avoid the process sentinel pile-up: > > The preview provider should return its callback function to Org so Org > can run it at its convenience. > > Org runs (funcall #'preview-func ov path link) > > preview-func returns either > 1. t, if preview is synchronous and successful, > 2. nil, if preview is synchronous but failed, > 3. A callback-func, if preview is asynchronous. In this case the > preview-func starts the network request or async job. > > Org adds callback-func to the queue of callback-funcs for this run, and > runs them spaced out on a timer or something. Preview success depends > on whether the callback-func returns t or nil. > > Implementing something like this should be easy with org-async, included > in the LaTeX preview patchset. > > But the process sentinels will run independent of Org's callback queue. > The callbacks only place the resulting image (or other metadata) on the > overlays. The bottleneck here is not the display engine, so this > doesn't solve the problem. > > Can you give me some more details of what you have in mind? I mostly meant calling preview-func asynchronously, while idle, spaced out, spending not longer than a fraction of second to call several preview-funcs. Spacing might then be controlled by the users. We might go further, and let the preview functions return a process. Then, we may explicitly control running sentinels just for that process via `accept-process-output'. But I am not sure if we need to go that far. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at