Re: [BUG] `org-html-head-include-scripts' default value should be `t' but it's nil instead [9.7-pre (release_9.6.20-1267-gb0c3c9 @ /home/nick/src/emacs/org/org-mode/lisp/)]

[Nick Dokos]

Ihor Radchenko  writes:

> Nick Dokos  writes:
>
>> If you load `ox-html`, the default value of
>> `org-html-head-include-scripts` is nil, despite the defcustom:
>>
>> (defcustom org-html-head-include-scripts t ...
>
> Are you sure? What I am seeing in lisp/ox-html.el is
>
> (defcustom org-html-head-include-scripts nil
>   "Non-nil means include the JavaScript snippets in exported HTML files.
> The actual script is defined in `org-html-scripts'."
>   :group 'org-export-html
>   :version "24.4"
>   :package-version '(Org . "8.0")
>   :type 'boolean)
>
> The default value is nil.

You are right (I was playing in an old branch and did not notice it at
the time). And although the theoretical possibility still exists, I
don't know of any other manifestation, so the question is moot at this
point.

Sorry for the noise.
-- 
Nick

[bug] Smart quotes: confusion of apostrophe with second level quotes

[Juan Manuel Macías]

Hi,

I don't know if this is a known issue, but I haven't been able to find
any mention of it. I think this is partly because in English it can go
perfectly unnoticed, since for English the values of secondary-closing
and apostrophe are identical:

  (secondary-closing :utf-8 "’" :html "" :latex "'" :texinfo "'")
  (apostrophe :utf-8 "’" :html "")

However, consider the following example:

  ━━━
  #+OPTIONS: ':t
  #+language:es

  "my friends' party and the students' papers"
  ━━━

the above produces in LaTeX:

  \guillemotleft{}my friends'' party and the students'' papers\guillemotright{}

In Spanish, as in other similar cases, the issue is easier to reproduce
because:

  (secondary-closing :utf-8 "”" :html "" :latex "''" :texinfo "''")
  (apostrophe :utf-8 "’" :html "")

I don't know whether to consider this a bug or a limitation in the
current implementation, originating from how Org interprets an
apostrophe. Although I suspect it has a difficult solution: how to
differentiate an apostrophe from a second-level quote in certain
scenarios, when the approach seems to be essentially heuristic? Let us
also consider cases in which the apostrophe can be placed at the
beginning of a word, as in Greek:

  "να 'ρθώ το βράδυ"

(Org would confuse the apostrophe in the word 'ρθώ with second-level
opening quotes)

Perhaps a possible solution would be to allow the use of a specific,
customizable character, other than an apostrophe, for second-level
quotes. Or at least add some brief warning in the manual: in certain
contexts it is safer to use a explicit Unicode character for the
apostrophe.

Best regards,

Juan Manuel

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: [BUG] `org-html-head-include-scripts' default value should be `t' but it's nil instead [9.7-pre (release_9.6.20-1267-gb0c3c9 @ /home/nick/src/emacs/org/org-mode/lisp/)]

[Ihor Radchenko]

Nick Dokos  writes:

> If you load `ox-html`, the default value of
> `org-html-head-include-scripts` is nil, despite the defcustom:
>
> (defcustom org-html-head-include-scripts t ...

Are you sure? What I am seeing in lisp/ox-html.el is

(defcustom org-html-head-include-scripts nil
  "Non-nil means include the JavaScript snippets in exported HTML files.
The actual script is defined in `org-html-scripts'."
  :group 'org-export-html
  :version "24.4"
  :package-version '(Org . "8.0")
  :type 'boolean)

The default value is nil.

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

[BUG] `org-html-head-include-scripts' default value should be `t' but it's nil instead [9.7-pre (release_9.6.20-1267-gb0c3c9 @ /home/nick/src/emacs/org/org-mode/lisp/)]

[Nick Dokos]

If you load `ox-html`, the default value of
`org-html-head-include-scripts` is nil, despite the defcustom:

(defcustom org-html-head-include-scripts t ...

The reason is that `org-expot-define-backend`, which is called earlier
in the file, contains the following line in the options alist:

   (:html-head-include-scripts nil "html-scripts" 
org-html-head-include-scripts)

and the call apparently binds `org-html-head-include-scripts' to nil, so
by the time the defcustom is evaluated, it's too late. I was confused by
that, but the description of `defcustom' in the Emacs Lisp Ref manual
states:

 The argument STANDARD is an expression that specifies the standard
 value for OPTION.  Evaluating the ‘defcustom’ form evaluates
 STANDARD, but does not necessarily bind the option to that value.
 If OPTION already has a default value, it is left unchanged.  If
 the user has already saved a customization for OPTION, the user’s
 customized value is installed as the default value.  Otherwise, the
 result of evaluating STANDARD is installed as the default value.

I verified that if I move the `defcustom' to before the
`org-export-defined-backend' call, everything works as expected.

See

   
https://emacs.stackexchange.com/questions/80783/org-mode-export-to-html-onmouseover-highlighting-of-referenced-code-lines

for the original question and the analysis.

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, 
cairo version 1.17.8)
 of 2023-12-28
Package: Org mode version 9.7-pre (release_9.6.20-1267-gb0c3c9 @ 
/home/nick/src/emacs/org/org-mode/lisp/)

-- 
Nick

Re: [BUG] Improve error message "org-back-to-heading: Before first headline at position 1" [9.6.8 (release_9.6.8-3-g21171d @/usr/local/share/emacs/29.1.50/lisp/org/)]

[Ihor Radchenko]

[ Adding Org mailing list back to CC ]

c.bu...@posteo.jp writes:

> Am 21.03.2024 11:46 schrieb Ihor Radchenko:
>> Are you saying that the above example will trigger an error on the
>> latest main when you try to attach a file?
>
> No, only the version (29.something) I reported this bug.
>
> "latest main" is to unstable for me.

Ok.
Since I cannot reproduce the problem on the latest main, but can on
bugfix, I am canceling this bug as it is fixed on main.
Canceled.

> Is there a stable version with this bug fixed?

No. It is only fixed on main.

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

[FR] Add customization for default answers to `org-attach-set/unset-directory' prompt (was: Org-attach risks)

[Ihor Radchenko]

[ Adding Org mailing list back to CC. Please use "Reply all" to keep the
  discussion public ]

Kepa  writes:

> I don't know enough to upload a patch, I barely know what is a patch...

No problem. Then, I will turn this discussion into a feature request.
It may be eventually implemented by other interested users.

> I was thinking, and if the default answer is (No) it could work: just 
> clicking ENTER ENTER, no file moving or deleting would take place.
> The danger would be if someday the default is (Yes) and people mechanically 
> send ENTER ENTER ...

We use yes/no prompt rather than (y/n) for a reason - it is a
destructive file operation.

What we may do instead is the following:

In addition to the sequence of prompts when changing the attachment
directory:

1. Copy over attachments from old attachment directory to new one?
2. Delete old attachment directory?

we can introduce a custom variable `org-attach-move-attachments' with
the following values:

1. 'ask (default) - display the prompts
2. 'move - move the attachments form old to new directory (same as yes,
   yes answer)
3. 'copy - copy the attachments, keeping the old directory (yes, no answer)
4. 'keep or nil - keep the attachments in the old directory (no, no answer)

I guess that no, yes answer that would delete the attachments is not
something we want to allow as automatic behavior.

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

Re: [BUG] org-agenda-clock-cancel does not update agenda buffer [9.6.15 (release_9.6.15 @ /nix/store/5hl68vr85cagmwaycqy652r2g2isjcyq-emacs-29.2/share/emacs/29.2/lisp/org/)]

[Ihor Radchenko]

z...@bcc32.com writes:

> After clocking into an entry (org-agenda-clock-in) from an agenda
> buffer (such as org-agenda-list), the entry is highlighted with a face
> (org-agenda-clocking).  When the entry is no longer clocked in, e.g.,
> by clocking out or marking it DONE, the org-agenda-clocking face is
> normally removed.
>
> However, org-agenda-clock-cancel is the exception, as it doesn't
> update the clocking entry's appearance.  Pressing r (org-agenda-redo)
> fixes the appearance.  I suspect org-agenda-clock-cancel just needs to
> call org-agenda-unmark-clocking-task.

Thanks for reporting!
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5dbf930c2

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

Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

[Ihor Radchenko]

Bruno Barbier  writes:

>> I feel that org-pending-penreg (org-pending-) is
>> redundant. Maybe better use org-pending-region?
>
> PENREG is the name of the structure; the "org-pending" is the
> mandatory library prefix; this mechanically gives the name.  A PENDREG
> object is not a "region" in Emacs sense.
>
> Do you see a better name for the structure PENREG, so that it doesn't
> sound like a "region" ?

Library prefix is also a part of the name and delivers useful
information. "org-pending-region" and "region" and not the same names.

We make use of prefix semantic in various places:
- org-export-backend, implying not just "backend", but also "export"
- org-cite-processor, implying not just "processor", but also "cite"
- org-lint-checker - "org-lint" + "checker"
- org-element-deferred - "org-element" + "deferred"

So, there is no need to duplicate information from the prefix - it is an
integral part of the struct name. Doing otherwise would go again the
existing naming in Org code base.

>> 1. It is not clear why you need a separate ~virtual~ field. When
>>~region~ is nil it already implies that the pending region is
>>virtual.
>
> It's a constant.  Calling a function looks more like we need to
> recompute it each time, and, we could even change it.  And
> cl-defstruct writes the function for us.
>
> Do you prefer a manually written function ?

Either a function or a clear indication in the docstring that ~virtual~
and ~region~ are connected and both read-only.

Also, ~virtual~ field is unused. So, maybe we can even drop it
completely. We can always add new fields in future, if a need arises.

>> 3. ~source~ field must match the ~region~ marker buffer. Then, why do we
>>need this field at all? May as well just use (marker-buffer (car region))
>
> The "source" is the region requesting the update.

The docstring of `org-pending' states that it is a buffer position:

The SOURCE is the buffer position that requested this pending region.

> ... The pending region
> is the "target" of the update, i.e. the region that will be updated.
>
>
> For example, in DEMO_ONLY, with org-babel, these 2 regions are never
> the same:
>1. the source is the source code block,
>2. the target (pending region) is the result region.

I am wondering why source must be a buffer position.
What if we want to mark a region pending for some task not associated
with a source? And why do we need to know the source at all?

>  2. insert-details: If, and only if, the user decides to
>  investigate what happened, Emacs will ask the task if it has any
>  details to add, that might help the user (like exit-code for an
>  OS process, stderr for an OS process or link to a log file, etc.)

I have to say that I am confused about "insert-details" part. Mostly
because it is not per se connected to the associated task. It is rather
an additional handler used to provide debug information about the task
status and outcome.

AFAIU, it is conceptually very similar to HANDLE-RESULT function.

I think that rather than handing HANDLE-RESULT and also TASK-CONTROL, we
may reduce everything to a single "handler" object that will serve as a
way for PENREG to communicate back to Elisp. That way, we do not need to
have a concept of a "task". Instead, it will be a familiar async API
with ability to (1) create (2) send signals to (3) receive signals from
PENREG object.

`org-pending' will be the entry point to create PENREG object.

`org-pending-ti-send-update' (or maybe simply
`org-pending-send-update'?) will be a way to send data to PENREG object.

HANLDER will be another object we may expose via something like
(org-pending-handler ( on-success-function on-cancel-function on-await 
on-insert-logs) ...)
Then, PENREG will call appropriate handler function as needed.

>>If the argument to ~org-pending-task-connect~ is a lambda, we can use
>>the current approach you implemented on the branch.
>
>> 2. ~org-pending-task-send-update~ name is confusing - it reads as if we
>>send an update _to_ the task. Maybe better ~org-pending-region-update~?
>
> Yes ... I wanted a common prefix for the 3 functions that a "task"
> implementation is allowed to use:
> - org-pending-task-connect,
> - org-pending-task-send-update,
> - org-pending-task-not-implemented.
>
> It's not confusing if one ignores the common prefix :-)
>
> I've renamed all these functions from "org-pending-task-" to
> "org-pending-ti-" where "ti" stands for "task implementation".

I still feel confused. As stated above, it might be a good idea to get
rid of the concept of "task" completely.

>>Then, we might even drop ~-sentinel~ field in org-pending-penreg
>>object and instead implement that hard-coded ~update~ lambda from
>>~org-pending~ as a part of ~org-pending-region-update~.
>
> That would require to manually capture (dump/load) the context that
> the sentinel closure is automatically capturing.
>
> Why would it be better ? 

Re: [BUG] Improve error message "org-back-to-heading: Before first headline at position 1" [9.6.8 (release_9.6.8-3-g21171d @/usr/local/share/emacs/29.1.50/lisp/org/)]

[Ihor Radchenko]

c.bu...@posteo.jp writes:

>> I believe that this problem have been fixed on main.
>
> Do you mean the message was improved or the message do not appear 
> anymore? Can you link please to the sources file where I can see the 
> message. Let's see if I understand it. :D

The error message should not appear anymore when you try to attach a
file before first heading.

>> If not, please provide more details on how to trigger the error.
>
> That is the simple example:
>
>  :PROPERTIES:
>  :ID:   a7f2b708-d2f9-41d5-a263-d82540b10b23
>  :END:
>  #+title: test2
>  #+date: [2024-03-10 16:42]
>  Paragraph
>
> After writing my first message I learned that there need to be a heading 
> that files are attached, too. I don't understand why. So I assume the 
> reason for the error message was that there is no heading in that org 
> file?

Are you saying that the above example will trigger an error on the
latest main when you try to attach a file?

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

Re: [BUG] Improve error message "org-back-to-heading: Before first headline at position 1" [9.6.8 (release_9.6.8-3-g21171d @/usr/local/share/emacs/29.1.50/lisp/org/)]

[c . buhtz]

Dear Ihor,
thanks for reply.

Am 21.03.2024 11:02 schrieb Ihor Radchenko:

 "org-back-to-heading: Before first headline at position 1 in
buffer..."


I believe that this problem have been fixed on main.


Do you mean the message was improved or the message do not appear 
anymore? Can you link please to the sources file where I can see the 
message. Let's see if I understand it. :D



If not, please provide more details on how to trigger the error.


That is the simple example:

:PROPERTIES:
:ID:   a7f2b708-d2f9-41d5-a263-d82540b10b23
:END:
#+title: test2
#+date: [2024-03-10 16:42]
Paragraph

After writing my first message I learned that there need to be a heading 
that files are attached, too. I don't understand why. So I assume the 
reason for the error message was that there is no heading in that org 
file?
But I would strongly disagree. An org file has a heading by definition 
even if it is empty. The heading string (#+title) might not exist and is 
empty but there is always an ":ID:". To my very(!) limited knowledge I 
would treat this behavior also as a bug. But there might be a good 
reason for this behavior.



Something is off in your email settings (in emacs or in system mailer).


I use Thunderbird. There are no other email settings. Never used Emacs 
with mails. I always wonder why debian-bugreport is able to send mails. 
:D

But copy & paste is good workaround in the first please.

Kind
Christian

inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks)

[Juan Manuel Macías]

Max Nikulin writes:

> I am afraid that :export will cause confusion with :exports for source 
> code blocks. Its name differs by just "s" but possible values have 
> nothing common.

I agree. At the moment two alternative names come to mind: :backends or
:export-rules

> Another issue is more general and should apply e.g. to HTML attributes 
> as well. Consider
>
> --- 8< ---
>
> #+options: inline-special-block-aliases:(("kbd" :export "html*" 
> :html-tag kbd))
>
> @kbd{Default} and @kbd[:export "latex*"]{LaTeX}
> --- >8 ---
>
> It exports to
>
>  \nDefault and LaTeX
>
> I would expect that "html*" is inherited from the parent declaration and 
> "latex*" does not override it, so
>
>  \nDefault and LaTeX

But it is the expected result in all attributes. If an attribute of the
same type as the one declared in the alias is added, the value is
overwritten.

In any case, since in this case the attribute allows cumulative values,
I think the approach should be at the level of the attribute name itself
and not the code to manage the export rules. For example:

:export [or whatever new name we give it] ==> normal behavior, overwrites the 
values

:export+ ==> adds the new values to the values defined in the alias

This syntax could also be extended to other cases. Perhaps we want
attributes like :prelatex, :postlatex, or :html to support accumulating
values. It could be easily solved from the functions of each backend. In
other cases, of course, it wouldn't make sense (a block can't have two
languages at the same time), but in that scenario, if someone puts
:lang+, it simply wouldn't be taken into account. Wdyt?

Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

[Bruno Barbier]

Ihor Radchenko  writes:

Thanks for your review Ihor!

> Bruno Barbier  writes:
>
>> I rewrote the API, rename many things, moved the code around and
>> sorted everything into heading/subheading sections.  This is hopefully
>> less confusing and a lot simpler; and the documentation hopefully
>> explains better how to use it.
>
> Thanks! It does look more clear.
>
>> The updated section "Commentary", in org-pending, describes the 3 steps
>> that are needed to mark and use a pending region: a PENREG (I've renamed
>> "PINFO" to "PENREG", for PENding REGion, more specific).
>
> I feel that org-pending-penreg (org-pending-) is
> redundant. Maybe better use org-pending-region?

PENREG is the name of the structure; the "org-pending" is the
mandatory library prefix; this mechanically gives the name.  A PENDREG
object is not a "region" in Emacs sense.

Do you see a better name for the structure PENREG, so that it doesn't
sound like a "region" ?


>> WDYT of this version ?
>
> Comments on org-pending-pendreg struct:
>
> 1. It is not clear why you need a separate ~virtual~ field. When
>~region~ is nil it already implies that the pending region is
>virtual.

It's a constant.  Calling a function looks more like we need to
recompute it each time, and, we could even change it.  And
cl-defstruct writes the function for us.

Do you prefer a manually written function ?


> 2. ~id~ field is semi-internal and assumed to be a number.
>Maybe we can do something more similar to Emacs process API:
>
>(make-process  ARGS)
>...
>:name NAME -- NAME is name for process.  It is modified if necessary
>to make it unique.
>
>We can replace id with human-readable name that can also be supplied
>when creating a pending region

Good idea. Done.


> 3. ~source~ field must match the ~region~ marker buffer. Then, why do we
>need this field at all? May as well just use (marker-buffer (car region))

The "source" is the region requesting the update.  The pending region
is the "target" of the update, i.e. the region that will be updated.


For example, in DEMO_ONLY, with org-babel, these 2 regions are never
the same:
   1. the source is the source code block,
   2. the target (pending region) is the result region.

I tried to improve the documentation of `org-pending-penreg' (source &
region).


> On the design of ~org-pending~ and ~org-pending-task-connect~:
>
> 1. I feel confused about the overall design of the interaction between
>pending region and the associated task.
>
>Functions like ~org-pending-task-send-update~ imply that pending
>region is rather decoupled from from associated task and the task
>should arrange manually for sending updates to the pending region
>object.

Exactly: the task implementation must use these ~org-pending-task-XXX~
functions to send updates to one (or more) pending region(s).


>On the other hand, there is ~task-connection~ that is used to kill
>associated task/process or to "await" for it. This time, pending
>region is strongly coupled with the task, killing it upon deleting
>the pending region.


These are optional features; and only ~org-pending~ will know if and
when those might be useful.  That's why the task needs to provide
callbacks here.
 1. cancel: Emacs may, in exceptional cases only,
 send a "cancel" to the task, meaning, "The user destroyed the
 pending region, and thus, Emacs will not use any update for it".

 2. insert-details: If, and only if, the user decides to
 investigate what happened, Emacs will ask the task if it has any
 details to add, that might help the user (like exit-code for an
 OS process, stderr for an OS process or link to a log file, etc.)

 3. get (await): It's an (unofficial) way, (in the degenerate case
 where the task implementation gives up on asynchronicity) to
 block until the outcome is available.  `org-pending' itself
 doesn't use it; DEMO_ONLY uses it with org-babel to define the
 synchronous executions.

>I think that we need more (optional) coupling between pending region
>and the associated task. We should be able to get more information
>about the task from pending region side - get logs, current status,
>exit status, etc.


>More specifically, I think that we need (1) allow to pass task as an
>argument for ~org-pending~.

That's actually what I started with, but, I couldn't make it work.

Breaking it like this is what allowed me to get the most generic and
simplest API that works for anything: threads, callbacks, OS processes,
timers.

If org-pending takes a "task" as an argument, then, we have to define
a universal API for whatever a "task" might be: threads, processes,
callbacks, timers, etc. and any combination of them.

It looks simpler to say that the "task" (whatever "task" means), MAY
call:
- org-pending-task-send-update (:progress xxx1)
- org-pending-task-send-update (:progress xxx2)
- 

Re: [BUG] Improve error message "org-back-to-heading: Before first headline at position 1" [9.6.8 (release_9.6.8-3-g21171d @/usr/local/share/emacs/29.1.50/lisp/org/)]

[Ihor Radchenko]

c.bu...@posteo.jp writes:

> This is not a support question about how to solve a problem or the error
> message I do report here. It is a request to improve that error message
> to help users understand the real problem and find a solution by their
> own.
>
> I get the this error message in context when using the Org attachments
> feature (C-c C-a plus c).
>
>  "org-back-to-heading: Before first headline at position 1 in 
> buffer..."

I believe that this problem have been fixed on main.
If not, please provide more details on how to trigger the error.

> using the first time this Emacs in build bug report thing. But have to 
> send the mail via copy & paste because the bug reporter didn't work out 
> of the box.
> The "From" field is not valid. Modified it manually in the buffer. But 
> didn't work.
> Emacs tried to use STARTTLS with posteo.de:25 which is wrong I think. 
> Should be port 587 but don't know how to set this.

Something is off in your email settings (in emacs or in system mailer).

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

[BUG] Improve error message "org-back-to-heading: Before first headline at position 1" [9.6.8 (release_9.6.8-3-g21171d @/usr/local/share/emacs/29.1.50/lisp/org/)]

[c . buhtz]

Hello,

using the first time this Emacs in build bug report thing. But have to 
send the mail via copy & paste because the bug reporter didn't work out 
of the box.
The "From" field is not valid. Modified it manually in the buffer. But 
didn't work.
Emacs tried to use STARTTLS with posteo.de:25 which is wrong I think. 
Should be port 587 but don't know how to set this.


OK, now the real problem:

This is not a support question about how to solve a problem or the error
message I do report here. It is a request to improve that error message
to help users understand the real problem and find a solution by their
own.

I get the this error message in context when using the Org attachments
feature (C-c C-a plus c).

"org-back-to-heading: Before first headline at position 1 in 
buffer..."


I have no idea about the brackground here. And I also not a regular user
of orgs attachment feature. So I can not provide a better error
message. This will be up to you. Thank you.

Kind
Christian Buhtz

Your bug report will be posted to the Org mailing list.




Emacs  : GNU Emacs 29.1.50 (build 1, aarch64-unknown-linux-gnu)
 of 2023-09-14
Package: Org mode version 9.6.8 (release_9.6.8-3-g21171d @ 
/usr/local/share/emacs/29.1.50/lisp/org/)


current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-roam-db-gc-threshold 314572800
 org-hide-emphasis-markers t
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

 org-download-file-format-function 'org-download-file-format-default
 org-roam-node-display-template #("${title:*} ${tags:20}" 11 21 (face 
org-tag))

 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)

 org-roam-find-file-hook '(org-roam-buffer--setup-redisplay-h
   org-roam--register-completion-functions-h
   org-roam--replace-roam-links-on-save-h
   org-roam-db-autosync--setup-update-on-save-h)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-edit-src-content-indentation 0
 org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-show-empty-lines

  org-cycle-optimize-window-after-visibility-change
  org-cycle-display-inline-images)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(#[0 "\301\211\207" [imenu-create-index-function
 org-imenu-get-tree] 2]
 buhtzology/org-mode-visual-fill org-bullets-mode
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-fold-show-all 
append

 local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook 
org-babel-show-result-all

 append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 buhtzology/org-mode-setup
 (closure (t) nil (display-line-numbers-mode 0)))
 org-roam-ref-annotation-function 'org-roam-ref-read--annotation
 org-roam-directory "~/.my.org-roam"
 org-ellipsis "↓"
 org-roam-db-node-include-function #[0 "\300\207" [t] 1]
 org-download-abbreviate-filename-function 'file-relative-name
 org-confirm-shell-link-function 'yes-or-no-p
 org-download-annotate-function 'org-download-annotate-default
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-roam-capture-preface-hook '(org-roam-capture--try-capture-to-ref-h)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-capture-prepare-finalize-hook 
'(org-roam-capture--install-finalize-h)

 org-roam-preview-function 'org-roam-preview-default-function
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)

 org-roam-db-autosync-mode t
 org-confirm-elisp-link-function 'yes-or-no-p
 org-log-buffer-setup-hook '(org-roam-log--setup)
 org-roam-capture-new-node-hook 
'(org-roam-capture--insert-captured-ref-h)
 org-structure-template-alist '(("rc" . "src rconsole") ("r" . "src R") 
("pc"

 . "src PyCon")
("p" . "src Python") ("a" . "export 
ascii")

 ("c" . "center")
("C" . "comment") ("e" . "example") ("E"
 . "export")
("h" . "export html") ("l" . "export 
latex")

 ("q" . "quote")
("s" . "src") ("v" . "verse"))
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)

 org-bullets-bullet-list '("■" "○" "●" "○" "●" "○" "●")
 org-fold-core-isearch-open-function 'org-fold--isearch-reveal
 org-persist-before-write-hook 
'(org-element--cache-persist-before-write)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)

 org-link-shell-confirm-function 

Re: Error with org-persist

[Ihor Radchenko]

Al Oomens  writes:

> (file-writable-p "c:/Users/aloom/My Drive/home/.emacs.d/org-persist") - 
> returns "t"
> ...
>> Evaluating (file-writable-p "c:/Users/aloom/My Drive/home/.emacs.d/") 
>> returns "nil".

The problem is that you do not seem to have write access to create files
in "c:/Users/aloom/My Drive/home".

This is a bug in Org mode that it checks for write access there (we
check one parent directory too much).
I fixed the check on the bugfix branch.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ad0282533
The fix will be available in the next Org bugfix release (likely tomorrow).

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