[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] New remote resource download policy
From: |
Timothy |
Subject: |
Re: [PATCH] New remote resource download policy |
Date: |
Wed, 22 Jun 2022 18:01:30 +0800 |
User-agent: |
mu4e 1.6.11; emacs 28.0.92 |
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,
Timothy