From: Timothy <email@example.com> To: Max Nikulin <firstname.lastname@example.org> Cc: email@example.com Subject: Re: [PATCH] New remote resource download policy Date: Wed, 22 Jun 2022 18:01:30 +0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> [-- 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, Timothy
next prev parent 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 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] New remote resource download policy' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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).