Max Nikulin writes:
>> [...]> The prompt is displayed twice because fetching is attempted twice
>> - when
>> reading startup options and when initializing macros. This is
>> sub-optimal, but expected.
>
> Are names of macros necessary for some purpose before export is started?
With the current
On 03/02/2024 03:03, Ihor Radchenko wrote:
Max Nikulin writes:
#+setupfile: http://localhost:8000/setup-1234567890.org
I am trying to decline attempts to download the remote resource by
hitting "n" (skip), but Org still tries to fetch that file and does it
twice. I see in the *Messages*
[...]>
Leo Butler writes:
> So, it is *possible* to have the setupfile set-up arbitrary elisp code
> that would be evaluated at some later time (during export or src block
> evaluation, as you wrote)? Is that correct?
Yes. That's why we prompt when SETUPFILE is remote.
--
Ihor Radchenko // yantar92,
On Mon, Feb 05 2024, Ihor Radchenko wrote:
> Leo Butler writes:
>
>> Q: if #+setupfile points to a real file available to download, does Org
>> evaluate that file?
>
> keywords and startup options are taken from there. No Elisp code present
> in #+SETUPFILE is evaluated.
>
> That said, if the fi
Leo Butler writes:
> Q: if #+setupfile points to a real file available to download, does Org
> evaluate that file?
keywords and startup options are taken from there. No Elisp code present
in #+SETUPFILE is evaluated.
That said, if the file defines babel header arguments with elisp or
"eval" mac
On Sun, Feb 04 2024, Max Nikulin wrote:
> On 03/02/2024 02:04, Leo Butler wrote:
>> When I opened your email in Gnus, I was greeted with the same
>> (bewildering) message. Given that Org still tried to download the
>> setupfile after being told not to, I think this is a majour security
>> hole.
>
Max Nikulin writes:
>> Please confirm that the fix works on your side.
>
> I have tried it with this specific scenario: open such a file (not a
> mail message with an attachment) with http: URIs. "Skip" works as
> expected now. I am unsure if any kind of remote files is blocked.
Thanks for che
On 03/02/2024 02:04, Leo Butler wrote:
When I opened your email in Gnus, I was greeted with the same
(bewildering) message. Given that Org still tried to download the
setupfile after being told not to, I think this is a majour security
hole.
This is also related to another thread concerning Org
Max Nikulin writes:
> However it may be unclear for users that setting `t' for
> `org-resource-download-policy' is dangerous if they use Emacs as a mail
> client or as a handler for opening links to .org files in browsers. I
> would consider adding "dangerous" to the label of this option and a
On 03/02/2024 03:03, Ihor Radchenko wrote:
Max Nikulin writes:
--- 8< ---
#+setupfile: http://localhost:8000/setup-1234567890.org
test
--- >8 ---
[...]
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=56748ea4e
Please confirm that the fix works on your side.
Max Nikulin writes:
> --- 8< ---
> #+setupfile: http://localhost:8000/setup-1234567890.org
>
> test
> --- >8 ---
>
> I am trying to decline attempts to download the remote resource by
> hitting "n" (skip), but Org still tries to fetch that file and does it
> twice. I see in the *Messages*
Fixe
On Fri, Feb 02 2024, Max Nikulin wrote:
> Hi,
>
> Org git main HEAD, try to open the following file:
>
> --- 8< ---
>
> #+setupfile: http://localhost:8000/setup-1234567890.org
>
> test
> --- >8 ---
>
> I am trying to decline attempts to download the remote resource by
> hitting "n" (skip), but O
Hi,
Org git main HEAD, try to open the following file:
--- 8< ---
#+setupfile: http://localhost:8000/setup-1234567890.org
test
--- >8 ---
I am trying to decline attempts to download the remote resource by
hitting "n" (skip), but Org still tries to fetch that file and does it
twice. I see in
13 matches
Mail list logo