Re: Seeing all the steps when I run an R code block

[William Denton]

On Tuesday, April 9th, 2024 at 09:03, Ihor Radchenko  
wrote:

> > Here's one big problem. I have a file, /home/wtd/books/reading/test-r.org, 
> > and
> > in it is this R block:
> > 
> > # -
> > 
> > #+begin_src R :session R:testing :results value
> > 1
> > #+end_src
> > 
> > # -
> > 
> > If I execute that with C-c C-c, the R session buffer starts, but in the 
> > wrong
> > working directory. This is in the R session buffer, reported by ESS:
> > 
> > # -
> > 
> > > setwd('/home/wtd/books')
> 
> 
> I just tested with the latest version of ESS and I am no longer able to
> reproduce the problem.
> 
> Do you still see it on your side?

Thanks for following up.  No, I don't see it any more ... an ESS upgrade or 
something fixed the problem.

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: Using org-latex-preview in other major modes

[Tony Zorman]

On Sun, Apr 07 2024 23:36, Karthik Chikmagalur wrote:
> You can ignore `org-latex-preview-live--src-buffer-setup', this is for
> previewing when using `org-edit-special' (C-c '), which does not apply
> to any other major mode.  So `org-latex-preview-live--ensure-overlay' is
> the only function you need to rewrite, which should be easy.

Oh, indeed, you are right; seems like it only looked intimidating! I
quickly hacked this in just now, and it works just fine.

As a very brief summary, one currently needs to—in addition to supplying
a preamble and a way to recognise maths and environments—patch the
following functions:

  · org-latex-preview--place-from-elements
  · org-latex-preview-auto--regenerate-overlay 
  · org-latex-preview-auto--maybe-track-element-here
  · org-latex-preview-live--ensure-overlay

The last two are only needed for the "live" part of the live previews to
work.

I will clean the code up a little bit (hopefully by the weekend, but no
promises), and try to add support for LaTeX environments instead of just
maths. I reckon that once this is finished one can get a pretty good
idea in which direction org-latex-preview.el would need to be nudged to
more easily facilitate this kind of integration. After that I guess
there's still the issue of caching and numbering, but I'll cross that
bridge once we get to it :)

  Tony

-- 
Tony Zorman | https://tony-zorman.com/

Re: [Q] startup hook: How do I detect if the current buffer has been opened programmatically?

[Rudi C]

`find-file-hook` seems not to have false negatives, at least. Using
`(window-live-p (get-buffer-window (current-buffer) 'visible))` has false
negatives for me (i.e., it returns nil for some interactive buffers).

Thanks, everyone.

On Tue, Apr 9, 2024 at 11:06 PM Karthik Chikmagalur <
karthikchikmaga...@gmail.com> wrote:

> >> Org-mode occasionally opens files automatically, for instance, when
> >> inserting or opening ID links, or during certain searches. I need to
> >> determine if a buffer was opened programmatically or manually by the
> user
> >> within the startup hooks. This distinction is important because, e.g., I
> >> want to automatically preview all LaTeX fragments if the buffer was
> opened
> >> by the user, but not if it was opened programmatically.
> >
> > AFAIK, there is no reliable way to do this.
> > You may play around with `find-file-hook'. See `org-with-file-buffer'
> > macro in org-macs.el (on main).
>
> A heuristic I use is to check if the window is visible.  It's not
> perfect but good enough for my use (which includes previewing LaTeX
> fragments):
>
> (defun my/latex-preview-maybe ()
>   (when (window-live-p (get-buffer-window (current-buffer)))
> (org-latex-preview 'buffer)
> (org-latex-preview-auto-mode 1)))
>
> (add-hook 'org-mode-hook #'my/latex-preview-maybe)
>
> Karthik
>

Re: [Q] startup hook: How do I detect if the current buffer has been opened programmatically?

[Karthik Chikmagalur]

>> Org-mode occasionally opens files automatically, for instance, when
>> inserting or opening ID links, or during certain searches. I need to
>> determine if a buffer was opened programmatically or manually by the user
>> within the startup hooks. This distinction is important because, e.g., I
>> want to automatically preview all LaTeX fragments if the buffer was opened
>> by the user, but not if it was opened programmatically.
>
> AFAIK, there is no reliable way to do this.
> You may play around with `find-file-hook'. See `org-with-file-buffer'
> macro in org-macs.el (on main).

A heuristic I use is to check if the window is visible.  It's not
perfect but good enough for my use (which includes previewing LaTeX
fragments):

(defun my/latex-preview-maybe ()
  (when (window-live-p (get-buffer-window (current-buffer)))
(org-latex-preview 'buffer)
(org-latex-preview-auto-mode 1)))

(add-hook 'org-mode-hook #'my/latex-preview-maybe)

Karthik

Re: When src block result is an image, how to define caption, html and latex attributes ?

[Ihor Radchenko]

Sébastien Gendre  writes:

>> P.S.
>>
>> We should really indicate the difference between normal and affiliated
>> keywords better.
>
> What do you mean ?

You are not the first person stumbling upon this exact wrinkle with src
block results. So, it would be nice to address it somehow.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: When src block result is an image, how to define caption, html and latex attributes ?

[Sébastien Gendre]

Ihor Radchenko  writes:

> P.S.
>
> We should really indicate the difference between normal and affiliated
> keywords better.

What do you mean ?

Re: When src block result is an image, how to define caption, html and latex attributes ?

[Ihor Radchenko]

Sébastien Gendre  writes:

> Example, before regenerate the source block result:
>
>
>
> #+CAPTION: Test image
> #+HTML_ATTR: :width 30px
> #+RESULTS:
> [[file:images/simple-test.png]]

You have a typo in one of the affiliated keywords.
Should be

#+ATTR_HTML: :width 30px

#+HTML_ATTR: is a very different construct - a full keyword rather than
affiliated keyword. So Org mode sees your

#+CAPTION: Test image
#+HTML_ATTR: :width 30px

and then 

#+RESULTS:
[[file:images/simple-test.png]]

as two separate paragraph-like elements, while babel is only looking at
the first following elements for an existing result when the block is
not named.

P.S.

We should really indicate the difference between normal and affiliated
keywords better.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: When src block result is an image, how to define caption, html and latex attributes ?

[Sébastien Gendre]

If I name the source block, it work.

Is it because:

* When a source block is named, it's result is also named

* When a result is named, Org-mode can locate it and replace its value

* But when a result is not named, Org-mode insert a #+RESULTS: just
  after the block and create a new one if it cannot found the previous
  one right after the block

?


"Fraga, Eric"  writes:

> On Tuesday,  9 Apr 2024 at 16:11, Sébastien Gendre wrote:
>> If I add them manually after the result generation, and generate again
>> the result, the #+CAPTION, #+LATEX_ATTR and #+HTML_ATTR are moved after
>> the result.
>
> Does this happen if your src block is NAMEd?

Re: When src block result is an image, how to define caption, html and latex attributes ?

[Sébastien Gendre]

If I place the #+CAPTION: and #+HTML_ATTR before the #+RESULTS:, then
generate again the result of the source block, I got a new #+RESULTS: on
top of the previous and its caption and html attributes.

Example, before regenerate the source block result:



#+CAPTION: Test image
#+HTML_ATTR: :width 30px
#+RESULTS:
[[file:images/simple-test.png]]



And after regenerate the source block result:



#+RESULTS:
[[file:images/simple-test.png]]

#+CAPTION: Test image
#+HTML_ATTR: :width 30px
#+RESULTS:
[[file:images/simple-test.png]]



My version of Org-mode is 9.6.15


Ihor Radchenko  writes:

> Sébastien Gendre  writes:
>
>> When a source block create a result who is an image, how can I define
>> the #+CAPTION, #+LATEX_ATTR and #+HTML_ATTR of this image ?
>>
>> If I add them manually after the result generation, and generate again
>> the result, the #+CAPTION, #+LATEX_ATTR and #+HTML_ATTR are moved after
>> the result.
>
> I am unable to reproduce. The updated result does not displace the
> affiliated keywords on my side, using the latest main and the latest
> stable Org mode version.

Re: [BUG] org-element-at-point warning with org-timer in agenda [9.7-pre, release_N/A-N/A-b45b39 @ /home/bhavin/.emacs.d/elpa/org-9.7pre0.20240405.140341/, ]

[Bhavin Gandhi]

Here is a patch which fixes the problem.
From d34e2cd1a1e830acc6d1575a32522f8e9e5b4d99 Mon Sep 17 00:00:00 2001
From: Bhavin Gandhi 
Date: Mon, 8 Apr 2024 23:33:29 +0530
Subject: [PATCH] org-timer-set-timer: Don't run `org-entry-get' in non Org
 buffers

* lisp/org-timer.el (org-timer-set-timer): Avoid calling org-entry-get
when we are not in an Org buffer. In case of Agenda buffer, we jump to
the entry first.

It was triggering an org-element warning when used in Agenda buffer,
and was failing to find the value of Effort property.

This patch is based on a fix by Ihor
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a1fa52197

Reported-by: Bhavin Gandhi 
Link: https://list.orgmode.org/CAOn=hbez7-4wfg2m1-mshqawvv0mysvlauyp9_gk6mrsbtz...@mail.gmail.com/
---
 lisp/org-timer.el | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/lisp/org-timer.el b/lisp/org-timer.el
index 8bb8be7be..23bb1c31c 100644
--- a/lisp/org-timer.el
+++ b/lisp/org-timer.el
@@ -424,9 +424,14 @@ using three \\[universal-argument] prefix arguments."
 	   (if (numberp org-timer-default-timer)
 	   (number-to-string org-timer-default-timer)
 	 org-timer-default-timer))
-	 (effort-minutes (let ((effort (org-entry-get nil org-effort-property)))
-			   (when (org-string-nw-p effort)
-			 (floor (org-duration-to-minutes effort)
+	 (effort-minutes
+  ;; When called from Org buffer, remain in position.
+  ;; When called from Agenda buffer, jump to headline position first.
+  (org-with-point-at (org-get-at-bol 'org-marker)
+(if (derived-mode-p 'org-mode)
+(let ((effort (org-entry-get nil org-effort-property)))
+		  (when (org-string-nw-p effort)
+		(floor (org-duration-to-minutes effort)))
 	 (minutes (or (and (numberp opt) (number-to-string opt))
 		  (and (not (equal opt '(64)))
 			   effort-minutes
-- 
2.44.0

Link to #ID-id:

[Daniel Clemente]

Hi,
  after updating org-mode and emacs to latest commits, I have seen that
some links to IDs in different files are exported like this:
some link: link

  Shouldn't it be?:   otherfile.html#c5m2je81pue0

  I didn't have time to debug this yet or see if it's from my setup. I may
do it in the next days.

Re: When src block result is an image, how to define caption, html and latex attributes ?

[Fraga, Eric]

On Tuesday,  9 Apr 2024 at 16:11, Sébastien Gendre wrote:
> If I add them manually after the result generation, and generate again
> the result, the #+CAPTION, #+LATEX_ATTR and #+HTML_ATTR are moved after
> the result.

Does this happen if your src block is NAMEd?

-- 
: Eric S Fraga, with org release_9.6.23-1314-g945046 in Emacs 30.0.50

Re: When src block result is an image, how to define caption, html and latex attributes ?

[Ihor Radchenko]

Sébastien Gendre  writes:

> When a source block create a result who is an image, how can I define
> the #+CAPTION, #+LATEX_ATTR and #+HTML_ATTR of this image ?
>
> If I add them manually after the result generation, and generate again
> the result, the #+CAPTION, #+LATEX_ATTR and #+HTML_ATTR are moved after
> the result.

I am unable to reproduce. The updated result does not displace the
affiliated keywords on my side, using the latest main and the latest
stable Org mode version.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Using org-latex-preview in other major modes

[Ihor Radchenko]

Karthik Chikmagalur  writes:

>> We may go even further, and extend the previews to be not just for
>> LaTeX. Might as well preview html/image links/pdf links/etc.
>
> I agree in principle but I think this is difficult to do with
> org-latex-preview because the async process chain and overlay handling are
> highly tuned for low-latency LaTeX processing.[1] 
>
> I do think Emacs could use a generic link-preview package, with an
> org-link-preview adapter for Org mode.

What I had in mind is something yet more generic:

1. preview.el abstracting away an API to toggle previews in
   buffer/region and display previews in separate buffer/echo area.
   It will provide customization on what kinds of previews are to be
   displayed; and the underlying backends will add themselves to some
   kind of hook that will do the actual work.

2. latex-preview.el with generic API to preview latex fragments in
   particular (or maybe even generic fragments that require to run
   convertor code -> image).

3. org-latex-preview with Org specific code.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [Q] startup hook: How do I detect if the current buffer has been opened programmatically?

[Ihor Radchenko]

Rudi C  writes:

> Org-mode occasionally opens files automatically, for instance, when
> inserting or opening ID links, or during certain searches. I need to
> determine if a buffer was opened programmatically or manually by the user
> within the startup hooks. This distinction is important because, e.g., I
> want to automatically preview all LaTeX fragments if the buffer was opened
> by the user, but not if it was opened programmatically.

AFAIK, there is no reliable way to do this.
You may play around with `find-file-hook'. See `org-with-file-buffer'
macro in org-macs.el (on main).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Update contact info

[Ihor Radchenko]

Amy Grinn  writes:

> I would like to update my old contact info in this project.
> ...
> +Amy Grinn  Tyler Grinn 

We have one commit under your name:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e268e479718e04f590324a29036f081a3f80f208

Bastien, may you check which name is used in the FSF records?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Max Nikulin  writes:

> On 09/04/2024 15:52, Ihor Radchenko wrote:
>> Aside: It looks like your public branch is not up-to-date as the time
>>of writing this email - I do not see commits changing the syntax to
>>@foo{...} and @@{...} yet,
>
> Do you have in your local copy the following?
> ...

I do now. Apparently, I somehow reviewed an earlier local copy of the
branch.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

When src block result is an image, how to define caption, html and latex attributes ?

[Sébastien Gendre]

Hello,


When a source block create a result who is an image, how can I define
the #+CAPTION, #+LATEX_ATTR and #+HTML_ATTR of this image ?

If I add them manually after the result generation, and generate again
the result, the #+CAPTION, #+LATEX_ATTR and #+HTML_ATTR are moved after
the result.

In org-babel documentation, I didn't found any header argument like
":result-caption" or something similar. There is a post processing, but
I cannot found the list of available post processing actions and their
config.


Best regards

Re: Persisting the current working directory in an org-babel session

[Ihor Radchenko]

Ihor Radchenko  writes:

>> For example, consider the following:
>>
>>  * Literate programming in a single session
>>  :PROPERTIES:
>>  :header-args: :var DIR="/Users/adam/Desktop/test"
>>  :END:
>>
>>  #+BEGIN_SRC emacs-lisp :session *elisp*
>>  (cd DIR)
>>  #+END_SRC
> ...
> Confirmed.

Hmm... I am looking at this again, and there is actually no bug here:

1. ob-emacs-lisp.el does not support sessions, so :session *elisp* does
   not thing in this case

2. without :session, Org babel does the following:

   16.4 Environment of a Code Block
   ...
   The ‘dir’ header argument specifies the default directory during code
   block execution. If it is absent, then the directory associated with the
   current buffer is used.

So, if we ever add session feature to ob-emacs-lisp, what was tried in
the report should be doable - one could retain working directory across
source blocks. But since ob-emacs-lisp does not support sessions, the
only actual problem is the fact that :session argument is silently
ignored without bringing absence of session support to the user
attention.

Handled, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d1c6f91ce

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Seeing all the steps when I run an R code block

[Ihor Radchenko]

William Denton  writes:

> Here's one big problem.  I have a file, /home/wtd/books/reading/test-r.org, 
> and 
> in it is this R block:
>
> # -
>
> #+begin_src R :session R:testing :results value
> 1
> #+end_src
>
> # -
>
> If I execute that with C-c C-c, the R session buffer starts, but in the wrong 
> working directory.  This is in the R session buffer, reported by ESS:
>
> # -
>
>> setwd('/home/wtd/books')

I just tested with the latest version of ESS and I am no longer able to
reproduce the problem.

Do you still see it on your side?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: columnview over file not working

[Ihor Radchenko]

Vlastimil Vondra  writes:

> OK, I found out that it is not working if the file (reading_list.org) is
> not opened in the buffer. If opened then it works all right.
>
> I guess it should be working like that.

Fixed, on bugfix.
The not-yet-open file will be automatically opened.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=67ec69976

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 09/04/2024 15:52, Ihor Radchenko wrote:

Aside: It looks like your public branch is not up-to-date as the time
   of writing this email - I do not see commits changing the syntax to
   @foo{...} and @@{...} yet,


Do you have in your local copy the following?

latest commit

ba2fc870c 2024-03-18 20:28:19 +0100 Juan Manuel Macías Chaín: * 
lisp/ox.el: More sensible export rules.


and

97a26a30d 2024-03-07 19:16:01 +0100 Juan Manuel Macías Chaín: * 
lisp/org-element.el: `@' instead of `_' for the anonymous variant.
b2b4d0177 2024-03-07 16:42:58 +0100 Juan Manuel Macías Chaín: * 
lisp/org-element.el: New syntax: `@' instead of `&'.


P.S. In your message I see most of my questions I have not asked.

Re: [BUG] Partially broken Org mode when remote setupfile is unavailable

[Max Nikulin]

On 09/04/2024 15:07, Ihor Radchenko wrote:

Ihor Radchenko writes:


#+setupfile: http://localhost:8000/setup-http-987.org

* Heading

[[https://orgmode.org/][Link]]

[...]

See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=5


The Emacs bug has been fixed.
There is no workaround we can employ on Org side other than waiting for
new Emacs releases with the fix in place.


I was considering a kludge with setting `org-resource-download-policy' 
to 'safe during loading of Org mode if its current value is 'prompt. I 
am unsure however if it is possible to detect whether the bug is fixed. 
I see several `defun' in the patch, so perhaps some of them might be 
leveraged for such test.

Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Finally, I have made public on GitLab my experimental branch for the new
> (possible) inline-special-block element:
>
> 

I have finally finished my review of the previous related discussions.
See my comments and proposals below.

[ Aside: It looks like your public branch is not up-to-date as the time
  of writing this email - I do not see commits changing the syntax to
  @foo{...} and @@{...} yet, as discussed in
  https://list.orgmode.org/orgmode/87sf121e9t.fsf@localhost/)
  I have edited your original message in the quotes to reflect upon the
  newly agreed syntax. ]

-

> The basic syntax:
> @foo{lorem ipsum dolor}

> There is also an anonymous variant:
> @@{lorem ipsum dolor}

> Optional attributes in square brackets are supported
> @foo[:key1 value1 :key2 value2 ...]{lorem ipsum dolor}

Let me list the main goals of the new inline markup within the scope of
overall Org markup and discuss whether the proposed syntax can work to
achieve them.

1. Introduce user-configurable ad-hoc syntax where exporting and
   fontification are fully configurable on Elisp level, per-document
   level, and maybe even per-markup level. Something combining
   flexibility of links and special blocks, but without their
   limitations:

   - In contrast to links, we should be able to nest inline markup
 without restrictions:

 @foo{@bar{text}} ([[foo:a][[[bar:b is not possible)

 ***This goal is covered by the branch***

   - We should be able to have arbitrary text inside inline markup.
 No sequence of symbols should be prohibited:

 @foo{ can contain leading and trailing spaces }
 @foo{can contain "}" inside, especially inside =verbatim }= text} <-- 
**ambiguous**
 @foo{can even have "}" at the end boundary}} <-- **ambiguous**
 This is unlike links that prohibit closing "]".

 ***For the above examples, the proposed syntax is ambiguous***

- We should be able to define special markup for code, where the
  contents is not parsed. Something like

  @code{ unlike =code=, we can have leading and trailing spaces }
  @code{ @foo{is not interpreted inside}}

  ***This goal is not addressed by the experimental branch for now***

2. Allow attaching auxiliary attributes to the on object level, as an
   equivalent of affiliated keywords on element level

   - For example, we should allow assigning height per-link without the
 awkward kludge we have with special handling of
 
 #+attr_html: :height 300
 [[file:image.png]] has a height of 300, but what if we want a
 different height in [[file:another-image.png]]?

 We can thus do
 
 #+attr_html: :height 300
 [[file:image.png]] has a height of 300, but what if we want a
 different height in @@[:html-height 300]{[[file:another-image.png]]}?

 Note how @@{...} markup assigns attributes to objects inside - the
 attributes should be somehow inherited.

 Another example is the proposed @@[:lang "en"]{...} attribute - we
 may want to assign it even beyond current paragraph; for example
 for the whole subtree (aka mark subtree language to be "English").

 ***This is not covered by the branch***

   - We should also be able to assign attributes that contain Org markup
 themselves:

 @@[:alt This image shows a _cat_ climbing a /wall/]{}

 ***This is not covered by the branch***

3. The new syntax should allow us to do anything Texinfo markup can do
   (as per RMS request 
https://list.orgmode.org/orgmode/87bkqx4jyg.fsf@localhost/)

   - Multi-argument markup in Texinfo like for abbreviations
 @abbr{abbreviation[,meaning]}

 Example: @abbr{Comput. J., Computer Journal}
 
(https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#g_t_0040abbr)

 We can equivalently (if markup inside attributes is supported) do

 @abbr[:meaning Computer Journal]{Comput. J.}
 or even
 @abbr[Computer Journal]{Comput. J.}

 In theory, we may need even more than 2 arguments.

 ***This is partially covered***

4. The new syntax should allow working around ambiguities of the *DWIM*
   markup without using the awkward zero-width space kludge

   - Intra-word markup

  foo@bold{bar}baz
  
  ***This is covered already***

   - Simultaneous markup
   
 @bold{foo}@italic{bar}
 @@{*foo*}@@{/bar/}

  ***This is covered already***

   - Solving the undesired first-fit-wins parser behaviour:

 /italics stops [[early/?here]], but not later/
 need to *escape stars* like that one*
 你好。*我*不会些这个

 @italic{italics stops [[early/?here]], but not later}
 need to @bold{escape stars* like that one}
 你好。@bold{我}不会些这个

  ***This is covered already***



Proposed modifications to the inline markup syntax
---

1. @foo{basic form remains the same}

2. @foo{{but we allow arbitrary number of "{{..." to open the 

Re: [BUG] Partially broken Org mode when remote setupfile is unavailable

[Ihor Radchenko]

Ihor Radchenko  writes:

>> --- 8< ---
>> #+setupfile: http://localhost:8000/setup-http-987.org
>>
>> * Heading
>>
>> [[https://orgmode.org/][Link]]
>> --- >8 ---
>>
>> I expect that inaccessible setupfiles are just ignored and Org should 
>> work as without "#+setupfile:" lines.
>
> This is because of another bug in Emacs.
> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=5

The Emacs bug has been fixed.
There is no workaround we can employ on Org side other than waiting for
new Emacs releases with the fix in place.
Closing.
Handled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at