emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Timothy <tecosaur@gmail.com>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] New remote resource download policy
Date: Wed, 22 Jun 2022 18:01:30 +0800	[thread overview]
Message-ID: <87pmj1nh7v.fsf@gmail.com> (raw)
In-Reply-To: <t8cjmu$du6$1@ciao.gmane.io>

[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]

Hi Max,

>> — a/lisp/org-attach.el
>> +++ b/lisp/org-attach.el
>> @@ -525,7 +525,11 @@ (defun org-attach-attach (file &optional visit-dir method)
>> [snip]
>> +        (if (or (not noninteractive) (org–should-fetch-remote-resource-p file))
> I am confused by (not noninteractive). Does it mean that interactive call is
> enough to bypass protection? It may have sense it at this step there is no
> ambiguity what resources is fetched. On the other hand I am unsure concerning a
> case when `org-attach-attach’ is a part of a larger command.

The idea here is that when this is done interactively the user will be aware of
the URL this is being applied to, and so it isn’t a risk. Let me know if this
assumption doesn’t hold.

>> +(defcustom org-download-remote-resources ’prompt
> The name sounds like some function.

Mmm. I could add `-policy' to that variable name perhaps.

>> +(defun org–confirm-resource-safe (uri)
>> +  “Ask the user if URI should be considered safe, returning non-nil if so.”
>> +    (unless noninteractive
>> +      (let ((buf (get-buffer-create “*Org Remote Resource*”)))
> I see your intention to add something fancy to the dialog. May `org-mks’ be
> reused instead to avoid proliferation variants of rather similar UI code?

Well, the thing here is that I’m explicitly trying to mimic the
file-local-variable dialog, and since a general form isn’t exposed by Emacs, a
little bit of proliferation seems like the best option to me.

>> +        ;; Set up the contents of the *Local Variables* buffer.
> I am in doubts concerning “once”. I tried “y” in a file having to “#+include:”
> of the same file. I did not get question for second include. I did not get
> prompt for this file anymore at all, even during next export. I modified the
> remote file, but stale content appeared during export. So the file was really
> downloaded once, but it is hardly in agreement with my expectations. Behavior is
> unrelated to this patch, concerning wording I am not sure, but I have no a
> better variant.

Ok, that is not the intended behaviour. I’ll see if I can work out what’s going
on here. Oh, and I should change that comment to “Set up the contents of the *Org
Remote Resource* buffer.”.

>> +                  (propertize “n” ’face ’error)
>> +                  “ to skip this resource.”)
> From “skip” I do not expect aborting of export.

Hmm, the “skip” action isn’t determined by the “is it safe” functions, but some
wording that doesn’t sound completely safe at least would be good.

> I have an idea but unsure if it should be implemented. Consider
> `org-remote-resources-policy’ custom variable that is a list of pairs
> (url-regexp . policy) for fine grain tuning instead of 2 variables. The price is
> more complicated structure, so higher chance of user error.

My initial reaction is that this feels like overkill.

All the best,

  reply	other threads:[~2022-06-22 10:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-12 14:43 [PATCH] New remote resource download policy Timothy
2022-06-12 16:18 ` Daniel Fleischer
2022-06-14  9:40 ` Robert Pluim
2022-06-22  9:58   ` Timothy
2022-06-15 12:35 ` Max Nikulin
2022-06-22 10:01   ` Timothy [this message]
2022-06-22 16:55     ` Max Nikulin
2022-06-29 15:27       ` Timothy
2022-06-30 16:57         ` Max Nikulin
2022-07-16  9:47           ` Timothy
2022-06-25  7:50     ` Max Nikulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pmj1nh7v.fsf@gmail.com \
    --to=tecosaur@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).