From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.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 qAyeKgFI02bCRgAAqHPOHw:P1 (envelope-from ) for ; Sat, 31 Aug 2024 16:42:41 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id qAyeKgFI02bCRgAAqHPOHw (envelope-from ) for ; Sat, 31 Aug 2024 18:42:41 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=I+zIEQLV; 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=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1725122561; 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=hMulpAJDR0rCxfJvu+2zLJ9mlSYcLUL1ysjanJNNmos=; b=WOsUkW1AK7J5zffLUrnoqsTWbC3V8Nv6VzGMWwLbwa8ri8Ok75kfuTYM+QPHJtnmM7h6NI naOUcqnSDxBY12rsMbvFXCUpDLFiV6tDJLVBRrcCRPRLxGX8/9Kg3926Q2mnF/Pzl1ACK8 bUU0A/cxX8ku3oa6rAhlC+DAwtLXJVngZCjium+ZGTmEhWA7OK5uj+MbnsRyRbu1nyIQZD 9yWFmO2DyUiS0ixB7L5B11rmlXdYPbKH8juHqe4DSbciEZ5rtvoqltjqnAdHtYX4WXSpMW xoBrRJOOLgcYiq9XaDgprkF/u7FjYQxMGoRQxQZ8NZSDO1lG5nXj1yw0QxAvDA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=I+zIEQLV; 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=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1725122561; a=rsa-sha256; cv=none; b=UjxVOV3dxKK1U/bvKrZbQfxn9mke1oHCkZYkBK5FHzVKTiAbRuoJvskd66gFHvPbfF3OwH mX79Z62zEkJn1tbcFbSkh5U6heLZ52EdmtLVQPlQ5wz65sSOYdDm/oZVOt3fDWCMHIXGDi 62RkSH0I9y7/GTvO4Y+4X4Date2ht6SmYVkRLCRBVOVKp+rKvmPESoPjhahPfqQfDah+KR dDslon0tD44B0+qp0wkzO53X49cwBANMC2cZkgYqx7VZXgJ/sq/LrypGpHsLmUIrH1wUBb fv0VH9YnUZjiT4RlTV5n2QTJ9T6xB+RR258p2PeOtooT9Yn5JT6dl0VE1fOHow== 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 0C5EA15206 for ; Sat, 31 Aug 2024 18:42:41 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1skRAl-00071b-J2; Sat, 31 Aug 2024 12:41:59 -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 1skRAj-00070x-Mf for emacs-orgmode@gnu.org; Sat, 31 Aug 2024 12:41:58 -0400 Received: from mail-il1-x12d.google.com ([2607:f8b0:4864:20::12d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1skRAh-0006lK-7k for emacs-orgmode@gnu.org; Sat, 31 Aug 2024 12:41:57 -0400 Received: by mail-il1-x12d.google.com with SMTP id e9e14a558f8ab-39f4f62a303so2373655ab.1 for ; Sat, 31 Aug 2024 09:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725122512; x=1725727312; darn=gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=hMulpAJDR0rCxfJvu+2zLJ9mlSYcLUL1ysjanJNNmos=; b=I+zIEQLVJTTGIWUUIL+z17nWOjY7HPY/Qu6G3Cxj42XBuDp6SdFCrJj4MwODPAa4cz EUXvwNP6U6OJs9OPURzt7yjcCHLusEn43gIJDTFsQWYdSs15uyKVVyTGwCY7eH1fPb4f yc2AbIOAbICD01uL99M0XMrC+4M0Srbt/GYMYq95N7VXRdulQD8xa93mRKDau/XEhNpy 32R3yF9bF703oJUBAXN0W2hv5Ftzncbdj/0ErQBnf5bgxettpahnVlNWlCw4Orkr0GvT X+ANYFdTvXZSO7C90+pso1x8XLZg7s4PwKJwCtRYrsuzwiEJczDhG8ai/yJbRxSXyH9e Xs9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725122512; x=1725727312; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hMulpAJDR0rCxfJvu+2zLJ9mlSYcLUL1ysjanJNNmos=; b=Z8dxCZaQtsb59Tq0DePROw3EpXI9qfXAN2vs11yCoDPCEHloLKkjYnsGjRvXT6ngYz RUr4HSUbUudfbYkoMow6pQRPKs0EGfj3zmSbsC19FwL6a8sH16lXFkDqE3zYufuCd+cb XUJ0UjaCoRCOX9UEGQfEYJzepjFaDdK4DWF/rIgdK/Gkj4VGyS4dHmRBef3dewHXkfYf lwn+8Ww4hNy7ji09oVKf5yrHoF8T6MiZxWGlCkBXaXqNYAENQTDDWk8yJRur6MWFTZL4 39CU0jsj4PsNSvNA7PSxpvMERPQEnUam4gXeTmLXDq7v0Z9z2a0d4mYmLJ8H+DYd35qN kgiQ== X-Forwarded-Encrypted: i=1; AJvYcCX/cOelhGP9RYZFsd1rWB/EngtNCDMjULXXhz6zMjC8KiQd4GTFXYfaSKOnZo3V69EYG5LKxR8+6NVNrrX2@gnu.org X-Gm-Message-State: AOJu0YyVICo4f/FKFYtsY1PasjPXWjm2EcQXho6Mr/9FNnLdl/ZUkQuM Dj9tzBNA4op/em9Sag3x29FpOVzcEFLDs9TjShD7trWyjjrAp4OD X-Google-Smtp-Source: AGHT+IHPOk+Q4a4kRUKy8TG+NQ2/uC3IDtPCJ96zb9oIOiv3xZ7YHWYVek7GSctRVPpBCk3tGKmSMQ== X-Received: by 2002:a05:6e02:219c:b0:39a:e9e5:62b with SMTP id e9e14a558f8ab-39f377cb507mr122253095ab.3.1725122512265; Sat, 31 Aug 2024 09:41:52 -0700 (PDT) Received: from localhost ([2600:8802:5726:2500:25e5:c7c1:4443:abba]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7d22e9dca2dsm4123771a12.94.2024.08.31.09.41.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Aug 2024 09:41:51 -0700 (PDT) From: Karthik Chikmagalur To: Ihor Radchenko Cc: stardiviner , Org mode Subject: Re: [PATCH v1] Inline image display as part of a new org-link-preview system In-Reply-To: <874j70n559.fsf@localhost> References: <6461a84b.a70a0220.b6d36.5d00@mx.google.com> <87zg3l1rgb.fsf@localhost> <64c8a313.a70a0220.93ee0.14fb@mx.google.com> <87il9zgpdp.fsf@localhost> <64c905d7.170a0220.f434a.fddb@mx.google.com> <87o7jpoqfl.fsf@localhost> <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> Date: Sat, 31 Aug 2024 09:41:50 -0700 Message-ID: <87msksabld.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::12d; envelope-from=karthikchikmagalur@gmail.com; helo=mail-il1-x12d.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, T_SCC_BODY_TEXT_LINE=-0.01 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: 0C5EA15206 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -9.80 X-Spam-Score: -9.80 X-TUID: Fl5pwLbAmkY4 Thanks Ihor. Before I send the next iteration of the patch, I'd like your input on some decisions marked with "Q:" below. >> Not yet handled or final: >> >> - Link abbreviations: I'm using org-link-any-re to find links, and this >> appears to be handling link abbreviations fine. So there is no >> special code to handle link abbreviations. But I'm not sure. > >> - The calling convention for the :preview function is not final. Right >> now it is given the overlay, the link type and the link path. But >> other link details can be required -- for example, image links need to >> read the org keywords for the image width and alignment, so I end up >> calling (org-element-context) again inside the :preview function. > > We may simply pass the link object to :preview function. If we pass the link object instead of the overlay, it will be the preview function's job to create overlays as needed. This overlay should have special properties (like `org-image-overlay') for previewing to work correctly. Q: Is this okay? Or did you mean we can pass both the link and the overlay, like this: (funcall preview-func ov link) and let the previewer figure out the link type and path details? >> Subject: [PATCH 2/2] org-link: Move inline image display to org-link > > Is there [PATCH 1/2]? There is no [PATCH 1/2], sorry about the naming. What I sent is the complete patch. >> * lisp/org-keys.el: Bind `C-c C-x C-v' to new command >> `org-link-preview', which has the same prefix arg behaviors as >> `org-latex-preview'. > > Didn't we discuss changes to the behavior? Yes, those changes have been implemented, please see the docstring for org-link-preview. The behavior is identical to that of org-latex-preview, but in addition the 1 and the 11 numeric prefix args are handled specially. >> +`:preview' >> + >> + Function to run when generating an in-buffer preview for the >> + link. It must accept three arguments: >> + - an overlay placed from the start to the end of the link. >> + - the link type, as a string. >> + - the path, as a string. > > Maybe we can ask the function to return non-nil when the preview is > going to happen. The current approach with "overlay deleted then no > preview" is not ideal. Good idea. >> +(defun org-link-preview--get-overlays (&optional beg end) >> + "Return link preview overlays between BEG and END." >> + (let* ((beg (or beg (point-min))) >> + (end (or end (point-max))) >> + (overlays (overlays-in beg end)) >> + result) >> + (dolist (ov overlays result) >> + (when (memq ov org-link-preview-overlays) >> + (push ov result))))) > > I know that this is a copy-paste, but we may utilize 'org-image-overlay > + `org-find-overlays' here. Noted. >> +(defun org-link-preview--remove-overlay (ov after _beg _end &optional _len) >> + "Remove link-preview overlay OV if a corresponding region is modified. >> + >> +AFTER is true when this function is called post-change." >> + (when (and ov after) >> + (setq org-link-preview-overlays (delete ov org-link-preview-overlays)) >> + ;; Clear image from cache to avoid image not updating upon >> + ;; changing on disk. See Emacs bug#59902. >> + (when (overlay-get ov 'org-image-overlay) >> + (image-flush (overlay-get ov 'display))) >> + (delete-overlay ov))) > > It implies that every :preview function _must_ put an image as 'display > property. If it does not, we will run into errors. But should it? This was an oversight, I meant to add (when-let ((disp (overlay-get ov 'display)) ((imagep disp))) (image-flush disp)) Will fix. > Also, when if preview is asynchronous, and we run this function when the > image is not yet assigned to the overlay? Handled by the above, plus the fact that we delete the overlay. It's up to the async callback to handle the case where the overlay no longer exists. >> + (cond >> + ((not (display-graphic-p)) >> + (message "Your Emacs does not support displaying images!")) > > May some third-party previews not require graphic? Good point, will handle. >> +(defun org-link-preview-clear (&optional beg end) >> + "Clear link previews in region BEG to END." >> + (interactive (and (use-region-p) (list (region-beginning) (region-end)))) >> + (let* ((beg (or beg (point-min))) >> + (end (or end (point-max))) >> + (overlays (overlays-in beg end))) >> + (dolist (ov overlays) >> + (when (memq ov org-link-preview-overlays) >> + (when-let ((image (overlay-get ov 'display)) >> + ((imagep image))) >> + (image-flush image)) >> + (setq org-link-preview-overlays (delq ov org-link-preview-overlays)) >> + (delete-overlay ov))) > > In asynchronous previews, some overlays may be deleted already. We > should be careful with this. Noted. >> +(defun org-link-preview-file (ov linktype path) >> + "Display image file PATH in overlay OV. >> + >> +LINKTYPE is the Org link type used to preview PATH, either >> +\"file\" or \"attachment\". >> + >> +Equip each image with the keymap `image-map'. >> + >> +This is intended to be used as the `:preview' link property of >> +file links, see `org-link-parameters'." >> + (if-let ((file-full >> + (if (equal "attachment" linktype) >> + (progn >> + (require 'org-attach) >> + (ignore-errors (org-attach-expand path))) >> + (expand-file-name path))) > > I'd rather put this part into org-attach, as a separate function that > calls `org-link-preview-file'. Q: I don't follow. Right now `org-link-preview-file' is the :preview org-link-parameter of file links and attachments. Could you explain how this indirection should work instead? Karthik