Re: [PATCH] Enhance org-html--build-meta-info
On 2021-01-04, TEC wrote: > Jens Lechtenboerger writes: > >> org-html--build-meta-entry and org-html--build-meta-info include some long >> lines. > > Hehe. We've had a lot of back-and-forth haven't we. > At least it feels like it's coming to a close now. On line 1432 I get this suggestion from flycheck: There should be two spaces after a period (emacs-lisp-checkdoc) More importantly, I just realized that for author information, org-html-plain-text is applied twice, leading to "amp;" when translating "&". (Once inside org-html-meta-tags-default, then in org-html--build-meta-entry.) This should not happen. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: recursive load org-duration Error
Mario Bourgoin writes:
> I recently started to use org mode efforts encoded as durations. I began
> getting the error "recursive load org-duration" after I customized
> "org-duration-units" by using "m" for the minutes units and "mon" for the
> months units, restarted Emacs, and asked for the agenda with "C-c a a".
>
> I found that a workaround to this problem is to put "(require
> 'org-duration)" in my .emacs before the customizations are loaded:
[...]
Thanks for the detailed report. I can trigger the issue with
(custom-set-variables
'(org-duration-units
'(("min" . 1)
("h" . 60)
("d" . 1440)
("w" . 10080)
("m" . 43200)
("y" . 525960.0
;; This...
(require 'org-duration)
;; or anything else the triggers a load of org-duration, e.g.
;; (org-duration-to-minutes "3m")
> Would you please let me know when this bug is fixed? I would also
> appreciate finding out how the bug was fixed.
It's fixed on the maint branch. See
https://code.orgmode.org/bzg/org-mode/commit/273391c978d2e9759a9a389bf5d5eb9b03b8fe98
[PATCH] Fix typo in f948234cb
--- contrib/lisp/org-contacts.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el index 82881ecd0..4b93de664 100644 --- a/contrib/lisp/org-contacts.el +++ b/contrib/lisp/org-contacts.el @@ -54,8 +54,8 @@ Usage: ;;; How to search? -;;; -;;; You can use `org-spare-tree' [C-c / p] to filter based on a +;;; +;;; You can use `org-sparse-tree' [C-c / p] to filter based on a ;;; specific property. Or other matcher on `org-sparse-tree'. ;;; Code: -- 2.26.2
Re: [PATCH] org-contacts.el: Only use org-id-store-link if org-id is loaded
miles christopher writes: > Thanks for your patch. :smile: > > Can you send patch file as attachment? I don't know how to apply patch in > email body. Hi Miles, If you download the raw email message (which you should be able to do in the Gmail UI) you can apply the patch like so: git am < /path/to/download.eml Alternatively, you can download the email from the orgmode list archives and apply the patch using this one-line command: curl -s https://orgmode.org/list/874kjxpqht@florness.com/raw | git am Let me know if you run into any trouble. -- David signature.asc Description: PGP signature
Re: [PATCH] org-contacts.el: Only use org-id-store-link if org-id is loaded
Thanks for your patch. :smile: Can you send patch file as attachment? I don't know how to apply patch in email body. David Florness writes: > Fixes bug introduced in 6b83c6e4e that made org-contacts-anniversaries > error if org-id was not loaded. > --- > Alternatively, we could autoload org-id-link-to-org-use-id. If you all > would prefer this, let me know and I can send a v2 patch. > > 6b83c6e4e was found using git-blame. > > contrib/lisp/org-contacts.el | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el > index 82881ecd0..7ad425519 100644 > --- a/contrib/lisp/org-contacts.el > +++ b/contrib/lisp/org-contacts.el > @@ -1166,7 +1166,7 @@ are effectively trimmed). If nil, all zero-length > substrings are retained." >"Store the contact in `org-contacts-files' with a link." >(when (and (eq major-mode 'org-mode) >(member (buffer-file-name) (mapcar 'expand-file-name > org-contacts-files))) > -(if org-id-link-to-org-use-id > +(if (and (featurep 'org-id) org-id-link-to-org-use-id) > (org-id-store-link) >(let ((headline-str (substring-no-properties (org-get-heading t t t > t > (org-store-link-props -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
org-export-with-tasks stops top level subtree export
org-export-with-tasks is a great setting. i set it to nil to make notes that will not be exported. === * REF ^A poem * NEXT fix this, or else keep it as is * Poem In Xanadu Kubla Khan did In a crass Ozymandian bid A huge dome decree That washed out to sea And was home to a tentacled squid === If - point is at ^ - the variable is set to nil - i export the SUBTREE, then it exports nothing. which is not particularly useful. i want REF to be there. i expected org to know i wanted to export, so it took me a long time to figure out why it did not. surprising. on the other hand, i have to admit the variable does what it says. and so would also be surprising if it did export something. so should SUBTREE exporting pointlessly export nothing in this case, or should it usefully export something? for me, it should violate consistency for just the top level. is there some filter magic to do that? -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [PATCH] ox-publish.el: Speed up org-publish-cache-file-needs-publishing
Thank you for the patch. Emily Bourke writes: > I found publishing when there were no changes to be slower than > expected. Profiling showed me that > `org-publish-cache-file-needs-publishing' was invoking the > `after-find-file' hooks, which I don't think is necessary. > > I've changed it to avoid doing that, by using `with-temp-buffer' and > `insert-file-contents', and noticed a significant increase in speed. > > Is there any reason I'm missing for using `find-file-noselect' in this > case? Nothing jumps out to me. For large files that are already visited, I suppose find-file-noselect returning an existing buffer can be faster, so relevant factors would include how many Org files a project has, how large they are, and how many of those are visited in the current session. My guess is that using with-temp-buffer and insert-file-contents would be a net gain, though that gain would be narrowed some if the temporary buffer was put into org-mode rather than kept in fundamental-mode (more below). > Subject: [PATCH] ox-publish.el: Speed up > org-publish-cache-file-needs-publishing > > * lisp/ox-publish.el (org-publish-cache-file-needs-publishing): Use > `with-temp-buffer' with `insert-file-contents' instead of > `find-file-noselect'. This avoids running the `after-find-file' hook, > which can make it significantly faster. This reads to me like after-find-file is the hook itself. Perhaps something like this would be clearer: "... avoids calling after-find-file and running find-file-hook, ...". > diff --git a/lisp/ox-publish.el b/lisp/ox-publish.el > index 7bb2fed6e..e967286cf 100644 > --- a/lisp/ox-publish.el > +++ b/lisp/ox-publish.el > @@ -1290,29 +1290,26 @@ the file including them will be republished as well." >(org-inhibit-startup t) >included-files-ctime) > (when (equal (file-name-extension filename) "org") > - (let ((visiting (find-buffer-visiting filename)) > - (buf (find-file-noselect filename)) > - (case-fold-search t)) > - (unwind-protect > - (with-current-buffer buf > - (goto-char (point-min)) > - (while (re-search-forward "^[ \t]*#\\+INCLUDE:" nil t) > - (let ((element (org-element-at-point))) > - (when (eq 'keyword (org-element-type element)) > - (let* ((value (org-element-property :value element)) > -(filename > - (and (string-match "\\`\\(\".+?\"\\|\\S-+\\)" value) > - (let ((m (org-strip-quotes > -(match-string 1 value > -;; Ignore search suffix. > -(if (string-match "::.*?\\'" m) > -(substring m 0 (match-beginning 0)) > - m) > - (when filename > - (push (org-publish-cache-ctime-of-src > -(expand-file-name filename)) > - included-files-ctime))) > - (unless visiting (kill-buffer buf) > + (let ((case-fold-search t)) > + (with-temp-buffer > + (insert-file-contents filename) > + (goto-char (point-min)) The goto-char call can be dropped now because insert-file-contents inserts after point. Unlike the previous code, this doesn't activate org-mode in the buffer. That gives a speedup. And I don't spot any code downstream that depends on the major mode being org-mode, so it's probably safe, though perhaps there's a subtle change in behavior here (e.g., related to syntax table). If org-mode isn't called, the org-inhibit-startup binding above could be dropped. > + (while (re-search-forward "^[ \t]*#\\+INCLUDE:" nil t) > + (let ((element (org-element-at-point))) > + (when (eq 'keyword (org-element-type element)) > + (let* ((value (org-element-property :value element)) > +(filename > + (and (string-match "\\`\\(\".+?\"\\|\\S-+\\)" value) > + (let ((m (org-strip-quotes > +(match-string 1 value > +;; Ignore search suffix. > +(if (string-match "::.*?\\'" m) > +(substring m 0 (match-beginning 0)) > + m) > + (when filename > + (push (org-publish-cache-ctime-of-src > +(expand-file-name filename)) This introduces a regression. With the previous code, the find-file-noselect call led to default-directory being set to the Org file's directory, and then this expand-file call on the included file was relative to that. With the new code, default-directory isn't changed, so it points to a non-existing or incorrect file unless the current default-directory and the Org file's happen to match. > +
Re: a few dead links on the babel languages page
Aloha, These should be fixed now. Thanks, Tom Greg Minshall writes: hi. here are a few dead links from https://orgmode.org/worg/org-contrib/babel/languages/index.html - http://ditaa.org/ditaa/ - ? s/b http://ditaa.sourceforge.net/ - http://www.mathomatic.org/ - http://www.mozart-oz.org/ cheers, Greg -- Thomas S. Dye https://tsdye.online/tsdye
[PATCH] org-contacts.el: Only use org-id-store-link if org-id is loaded
Fixes bug introduced in 6b83c6e4e that made org-contacts-anniversaries error if org-id was not loaded. --- Alternatively, we could autoload org-id-link-to-org-use-id. If you all would prefer this, let me know and I can send a v2 patch. 6b83c6e4e was found using git-blame. contrib/lisp/org-contacts.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el index 82881ecd0..7ad425519 100644 --- a/contrib/lisp/org-contacts.el +++ b/contrib/lisp/org-contacts.el @@ -1166,7 +1166,7 @@ are effectively trimmed). If nil, all zero-length substrings are retained." "Store the contact in `org-contacts-files' with a link." (when (and (eq major-mode 'org-mode) (member (buffer-file-name) (mapcar 'expand-file-name org-contacts-files))) -(if org-id-link-to-org-use-id +(if (and (featurep 'org-id) org-id-link-to-org-use-id) (org-id-store-link) (let ((headline-str (substring-no-properties (org-get-heading t t t t (org-store-link-props -- 2.30.0 signature.asc Description: PGP signature
Re: Problems with attachment links in exported files
Thanks Kyle!, While I was reading your message I checked that my org-mode version was outdated. I configured org-mode repository, but I didn't install the latest org-mode version. So I'm sorry for that. I've tried your snippet, and it works perfectly. Thank you for you time, I appreciate it. On Sun, Jan 3, 2021 at 9:46 PM Kyle Meyer wrote: > Pablo Palazon writes: > > > Hi everyone! > > > > I've had a trouble with attachment type link on exporting. I configured > > org-attach directory and using org-id and it works great on emacs, all > > those links work great. I can see any attach linked on org notes, but in > > exported files all those links point to local directory instead of the > > right attached folder. > > > [...] > > I tried to use > > > > (add-hook 'org-export-before-parsing-hook 'org-attach-expand-links) > > > > And it works except for inline images, but I don't understand why is not > on > > org-mode repository code. > > Hmm, I'm not sure what you mean by the last part. The snippet you show > is in the Org repo, specifically in org-attach.el: > > > https://code.orgmode.org/bzg/org-mode/src/release_9.4.4/lisp/org-attach.el#L750 > > I'm not an org-attach user, so I might be missing something obvious, but > I wasn't able to trigger the issue with inline links. Here's what I > tried using the default configuration on the master branch (c3888a8b7): > > (require 'org-attach) > (let ((default-directory (make-temp-file "org-attach-export-test-" t))) > (with-current-buffer (find-file-noselect "scratch.org") > (insert "* h1\n\n") > (org-attach-url >" > https://orgmode.org/worg/images/agenda/org-agenda-colorized-blocks.png;) > (insert "attachment:org-agenda-colorized-blocks.png") > (org-open-file (org-html-export-to-html > > That output includes > > > src="file:///tmp/org-attach-export-test-Surcu0/data/ad/4bdf8f-a28e-4621-a1e4-dc772ed6d531/org-agenda-colorized-blocks.png" > alt="org-agenda-colorized-blocks.png" /> > > and the image is rendered inline. > > Could you provide a minimal reproducer for the issue you see? >
Bug: inserting footnote when Footnotes heading has property drawer [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/user/.emacs.d/elpa/org-plus-contrib-20200309/)]
Hello! I seem to have come across a bug today in org-footnote. I had just learned about the variable org-footnote-auto-adjust and set it to t. Then I tried to test it by invoking org-footnote-new in my Org file in between existing footnotes 2 and 3. N.B., my Footnotes heading, prior to doing above also had a CUSTOM_ID property set: #+begin_src org ,** Footnotes :PROPERTIES: :CUSTOM_ID:footnotes :END: [fn:1] original footnote 1 [fn:2] original footnote 2 [fn:3] original footnote 3 [fn:4] original footnote 4 #+end_src The new footnote seems to get inserted into correct place, however there appears to be a problem if there is a property drawer: #+begin_src org ,** Footnotes [fn:1] original footnote 1 [fn:2] original footnote 2 [fn:3] new footnote :PROPERTIES: :CUSTOM_ID:footnotes :END: [fn:4] original footnote 3 [fn:5] original footnote 4 #+end_src Since I was just studying the org-footnote code anyway, I will attempt to further diagnose the issue, and perhaps even send a patch. As I was filling out bug report I realized I am on slightly dated version of Orgmode. So I went ahead and cloned latest version and did a diff on org-footnote.el between my affected version here locally and latest, and the only change I saw was the copyright date. So with that out of the way, I will start digging and see what I can come up with. Cheers, TRS-80 Emacs : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20) of 2020-05-16, modified by Debian Package: Org mode version 9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/user/.emacs.d/elpa/org-plus-contrib-20200309/)
Re: Tags LaTeX export question
On Sunday, 3 Jan 2021 at 21:08, Éric Würbel wrote: > How can I customize healine tags export to LaTeX ? You might be able to do something using filters. See org info manual: (org) Advanced Export Configuration There is a headline filter variable. Whether the tags come through or not is unclear to me, however. Easy enough to find out, I guess. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-166-g291993
Re: Tags LaTeX export question
Éric Würbel writes:
> Hi listers,
>
> How can I customize healine tags export to LaTeX ?
>
> The default settings provide a first line-break but then no more,
> resulting in a truncation in case of a large number of tags.
>
> I need this for a computational poem.
>
> Oh, and if the solution needs elisp programming, no problem, so
> pointing me on some king of hook will be ok.
By default, the headline is formatted with
(defun org-latex-format-headline-default-function
(todo _todo-type priority text tags _info)
"Default format function for a headline.
See `org-latex-format-headline-function' for details."
(concat
(and todo (format "{\\bfseries\\sffamily %s} " todo))
(and priority (format "\\framebox{\\#%c} " priority))
text
(and tags
(format "\\hfill{}\\textsc{%s}"
(mapconcat #'org-latex--protect-text tags ":")
You could write a custom variant and point
org-latex-format-headline-function to it. (Or at least I think that
should work; I haven't tested it myself.)
Re: Tags LaTeX export question
Thank you, I should have remembered this, as I already wrote a backend system for static html site generation which uses filters. For sure this is the way to go. Thanks again. E. Le dim. 03 janv. 2021 à 20:44, Eric S Fraga a écrit : > On Sunday, 3 Jan 2021 at 21:08, Éric Würbel wrote: >> How can I customize healine tags export to LaTeX ? > > You might be able to do something using filters. See org info manual: > (org) Advanced Export Configuration > > There is a headline filter variable. Whether the tags come through or > not is unclear to me, however. Easy enough to find out, I guess. -- http://www.vents-sauvages.fr/ gemini://retry-abort.org/ « Il faut toujours viser la lune, car même en cas d’échec, on atterrit dans les étoiles » Oscar WILDE
Re: Problems with attachment links in exported files
Pablo Palazon writes: > Hi everyone! > > I've had a trouble with attachment type link on exporting. I configured > org-attach directory and using org-id and it works great on emacs, all > those links work great. I can see any attach linked on org notes, but in > exported files all those links point to local directory instead of the > right attached folder. > [...] > I tried to use > > (add-hook 'org-export-before-parsing-hook 'org-attach-expand-links) > > And it works except for inline images, but I don't understand why is not on > org-mode repository code. Hmm, I'm not sure what you mean by the last part. The snippet you show is in the Org repo, specifically in org-attach.el: https://code.orgmode.org/bzg/org-mode/src/release_9.4.4/lisp/org-attach.el#L750 I'm not an org-attach user, so I might be missing something obvious, but I wasn't able to trigger the issue with inline links. Here's what I tried using the default configuration on the master branch (c3888a8b7): (require 'org-attach) (let ((default-directory (make-temp-file "org-attach-export-test-" t))) (with-current-buffer (find-file-noselect "scratch.org") (insert "* h1\n\n") (org-attach-url "https://orgmode.org/worg/images/agenda/org-agenda-colorized-blocks.png;) (insert "attachment:org-agenda-colorized-blocks.png") (org-open-file (org-html-export-to-html That output includes and the image is rendered inline. Could you provide a minimal reproducer for the issue you see?
Bug: completion-at-point wrongly called within shell code block [9.4 (9.4-17-g9a6689-elpaplus @ /Users/uSukhavati/.emacs.d/elpa/org-plus-contrib-20201005/)]
--text follows this line--
What exactly did you do?
I include a source code block for shell in an org-files.
Example:
#+begin_src shell
foo
#+end_src
Within that source code block I type RET (Return)
What did you expect to happen?
The cursor should jump to the next line, adding one empty line in the code
block.
What happened instead?
Instead completion-at-point is called and a minibuffer opens and promts for a
selection.
Workarround:
To prevent the minibuffer to open, I put an uneven number of quotation marks
anywhere before the code block.
Exmaple:
"""
#+begin_src shell
foo
#+end_src
Emacs : GNU Emacs 26.1.92 (build 1, x86_64-apple-darwin18.2.0, Carbon Version
158 AppKit 1671.2)
of 2019-04-03
Package: Org mode version 9.4 (9.4-17-g9a6689-elpaplus @
/Users/uSukhavati/.emacs.d/elpa/org-plus-contrib-20201005/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-babel-after-execute-hook '(spacemacs/ob-fix-inline-images)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-export-with-sub-superscripts '{}
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-refile-targets '((org-agenda-files :maxlevel . 3))
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-imenu-depth 8
org-download-annotate-function 'org-download-annotate-default
org-agenda-files '("~/org/arbeit/Arbeit.org"
"~/org/aws-labs/control-tower.org" "~/org/training/AwsTraining.org"
"~/org/meinleben/notes.org" "~/org/meinleben/MeinLeben.org"
"~/org/meinleben/Arbeit.org" "~/org/meinleben/CEB.org"
"~/org/training/KubernetesCKA.org"
"/Users/uSukhavati/org/meinleben/CEB.org"
"/Users/uSukhavati/org/meinleben/Emacs.org"
"/Users/uSukhavati/org/meinleben/Freizeit.org")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-modules '(ol-bbdb ol-bibtex ol-docview ol-eww ol-gnus ol-info ol-irc
ol-mhe ol-rmail ol-w3m drill)
org-mode-hook '(org-clock-load #[0 "\301\211\207"
[imenu-create-index-function org-imenu-get-tree] 2]
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-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
spacemacs/load-yasnippet toc-org-enable org-download-enable
org-bullets-mode spacemacs//org-babel-do-load-languages
flyspell-mode spacemacs/add-org-surrounds evil-org-mode
org-eldoc-load spacemacs//init-company-org-mode company-mode)
org-clock-persist 'history
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-agenda-restore-windows-after-quit t
org-confirm-elisp-link-function 'yes-or-no-p
org-startup-with-inline-images t
org-download-file-format-function 'org-download-file-format-default
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-export-with-broken-links t
org-babel-load-languages '((shell . t) (python . t) (emacs-lisp . t))
org-log-done 'time
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-attach-store-link-p 'attached
org-priority-lowest 68
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php)
("C" . c) ("C++" . c++) ("asymptote" . asy) ("bash" . sh)
("beamer" . latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg) ("screen" .
shell-script) ("shell" . sh) ("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-log-into-drawer t
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-todo-keywords '((sequence))
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-clock-persist-file "/Users/uSukhavati/.emacs.d/.cache/org-clock-save.el"
org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el") ("elisp"
. "el"))
Tags LaTeX export question
Hi listers, How can I customize healine tags export to LaTeX ? The default settings provide a first line-break but then no more, resulting in a truncation in case of a large number of tags. I need this for a computational poem. Oh, and if the solution needs elisp programming, no problem, so pointing me on some king of hook will be ok. Thanks. Regards. E. -- http://www.vents-sauvages.fr/ gemini://retry-abort.org/ « Ils étaient tous différents les uns des autres, et en cela exactement pareils à nous. » Haruki Murakami
Re: [PATCH] Enhance org-html--build-meta-info
Jens Lechtenboerger writes:
> org-html--build-meta-entry and org-html--build-meta-info include some long
> lines.
Hehe. We've had a lot of back-and-forth haven't we.
At least it feels like it's coming to a close now.
> For org-html-meta-tags-default, I suggest this as last line for the doc
> string (typos, active voice):
> Use document's plist INFO to derive relevant information for the tags.
Sounds good. Done.
--
Timothy
>From f3f7325ea77cc443387e69f65e899a9537606d80 Mon Sep 17 00:00:00 2001
From: TEC
Date: Mon, 14 Dec 2020 17:41:33 +0800
Subject: [PATCH 1/2] lisp/ox-html.el: make html meta tag builder nicer
* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The keyword value formatting is changed from `org-export-data' to
`org-html-encode-plain-text' to avoid potentially nesting HTML tags in
meta tags and the element, which would violate W3C.
---
lisp/ox-html.el | 118
1 file changed, 60 insertions(+), 58 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 03145e3..f18f8a2 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1835,78 +1835,80 @@ INFO is a plist used as a communication channel."
;;; Template
+(defun org-html--build-meta-entry
+(label identity content-format content-formatters)
+ "Build a meta tag using the provided information.
+
+Construct tag of form , or when CONTENT-FORMAT
+is present:
+
+Here {content} is determined by applying any CONTENT-FORMATTERS to the
+CONTENT-FORMAT and encoding the result as plain text."
+ (concat "\n"))
+
(defun org-html--build-meta-info (info)
"Return meta tags for exported document.
INFO is a plist used as a communication channel."
- (let* ((protect-string
- (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
- (let ((auth (plist-get info :author)))
+ (let* ((title (org-html-plain-text
+ (org-element-interpret-data (plist-get info :title)) info))
+ ;; Set title to an invisible character instead of leaving it
+ ;; empty, which is invalid.
+ (title (if (org-string-nw-p title) title ""))
+ (author (and (plist-get info :with-author)
+ (let ((auth (plist-get info :author)))
;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
- (fboundp 'coding-system-get)
- (coding-system-get org-html-coding-system
- 'mime-charset))
- "iso-8859-1")))
+ (and auth (org-html-plain-text
+ (org-element-interpret-data auth) info)
+ (charset (or (and org-html-coding-system
+ (fboundp 'coding-system-get)
+ (symbol-name
+ (coding-system-get org-html-coding-system
+ 'mime-charset)))
+ "iso-8859-1")))
(concat
(when (plist-get info :time-stamp-file)
(format-time-string
(concat "\n")))
- (format
- (if (org-html-html5-p info)
- (org-html-close-tag "meta" "charset=\"%s\"" info)
- (org-html-close-tag
- "meta" "http-equiv=\"Content-Type\" content=\"text/html;charset=%s\""
- info))
- charset) "\n"
+
+ (if (org-html-html5-p info)
+ (org-html--build-meta-entry "charset" charset)
+ (org-html--build-meta-entry "http-equiv" "Content-Type"
+ (concat "text/html;charset=" charset)))
+
(let ((viewport-options
(cl-remove-if-not (lambda (cell) (org-string-nw-p (cadr cell)))
(plist-get info :html-viewport
- (and viewport-options
- (concat
- (org-html-close-tag
- "meta"
- (format "name=\"viewport\" content=\"%s\""
- (mapconcat
- (lambda (elm) (format "%s=%s" (car elm) (cadr elm)))
- viewport-options ", "))
- info)
- "\n")))
+ (if viewport-options
+ (org-html--build-meta-entry "name" "viewport"
+ (mapconcat
+ (lambda (elm)
+ (format "%s=%s" (car elm) (cadr elm)))
+ viewport-options ", "
+
(format "%s\n" title)
- (org-html-close-tag "meta" "name=\"generator\" content=\"Org mode\"" info)
- "\n"
- (and (org-string-nw-p author)
- (concat
- (org-html-close-tag "meta"
- (format "name=\"author\" content=\"%s\""
- (funcall protect-string author))
- info)
- "\n"))
- (and (org-string-nw-p description)
- (concat
-
Re: [PATCH] Enhance org-html--build-meta-info
On 2021-01-03, TEC wrote: > Jens Lechtenboerger writes: > >> The doc strings of org-html-meta-tags and org-html-meta-tags-default >> need to be updated, they still mention author and title. > > Ah, yep. Fixed. > >> Also, please try checkdoc ;) > > Ahhh yes. Actually, I use flycheck (https://www.flycheck.org/), which displays warnings right away. org-html--build-meta-entry and org-html--build-meta-info include some long lines. For org-html-meta-tags-default, I suggest this as last line for the doc string (typos, active voice): Use document's plist INFO to derive relevant information for the tags. Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Enhance org-html--build-meta-info
Jens Lechtenboerger writes:
> The doc strings of org-html-meta-tags and org-html-meta-tags-default
> need to be updated, they still mention author and title.
Ah, yep. Fixed.
> Also, please try checkdoc ;)
Ahhh yes. Checkdoc, my old ~enemy~ /friend/.
I may have shied away from using this because of the litany of issues it
raises for the file. How I'd love to see a PR making the Org codebase
more consistently follow these guidelines. Then we could potentially do
something like integrate CI into the patch acception workflow.
Enough of that digression, as before: patches attached :)
--
Timothy.
>From de74dcbd51703439faafe96cbc1c60965f064eaa Mon Sep 17 00:00:00 2001
From: TEC
Date: Mon, 14 Dec 2020 17:41:33 +0800
Subject: [PATCH 1/2] lisp/ox-html.el: make html meta tag builder nicer
* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The keyword value formatting is changed from `org-export-data' to
`org-html-encode-plain-text' to avoid potentially nesting HTML tags in
meta tags and the element, which would violate W3C.
---
lisp/ox-html.el | 116
1 file changed, 58 insertions(+), 58 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 03145e3..4d277a2 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1835,78 +1835,78 @@ INFO is a plist used as a communication channel."
;;; Template
+(defun org-html--build-meta-entry (label identity content-format content-formatters)
+ "Build a meta tag using the provided information.
+
+Construct tag of form , or when CONTENT-FORMAT is present:
+
+
+Here {content} is determined by applying any CONTENT-FORMATTERS to the CONTENT-FORMAT and encoding
+the result as plain text."
+ (concat "\n"))
+
(defun org-html--build-meta-info (info)
"Return meta tags for exported document.
INFO is a plist used as a communication channel."
- (let* ((protect-string
- (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
- (let ((auth (plist-get info :author)))
+ (let* ((title (org-html-plain-text
+ (org-element-interpret-data (plist-get info :title)) info))
+ ;; Set title to an invisible character instead of leaving it
+ ;; empty, which is invalid.
+ (title (if (org-string-nw-p title) title ""))
+ (author (and (plist-get info :with-author)
+ (let ((auth (plist-get info :author)))
;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
- (fboundp 'coding-system-get)
- (coding-system-get org-html-coding-system
- 'mime-charset))
- "iso-8859-1")))
+ (and auth (org-html-plain-text
+ (org-element-interpret-data auth) info)
+ (charset (or (and org-html-coding-system
+ (fboundp 'coding-system-get)
+ (symbol-name
+ (coding-system-get org-html-coding-system
+ 'mime-charset)))
+ "iso-8859-1")))
(concat
(when (plist-get info :time-stamp-file)
(format-time-string
(concat "\n")))
- (format
- (if (org-html-html5-p info)
- (org-html-close-tag "meta" "charset=\"%s\"" info)
- (org-html-close-tag
- "meta" "http-equiv=\"Content-Type\" content=\"text/html;charset=%s\""
- info))
- charset) "\n"
+
+ (if (org-html-html5-p info)
+ (org-html--build-meta-entry "charset" charset)
+ (org-html--build-meta-entry "http-equiv" "Content-Type"
+ (concat "text/html;charset=" charset)))
+
(let ((viewport-options
(cl-remove-if-not (lambda (cell) (org-string-nw-p (cadr cell)))
(plist-get info :html-viewport
- (and viewport-options
- (concat
- (org-html-close-tag
- "meta"
- (format "name=\"viewport\" content=\"%s\""
- (mapconcat
- (lambda (elm) (format "%s=%s" (car elm) (cadr elm)))
- viewport-options ", "))
- info)
- "\n")))
+ (if viewport-options
+ (org-html--build-meta-entry "name" "viewport"
+ (mapconcat
+ (lambda (elm) (format "%s=%s" (car elm) (cadr elm)))
+ viewport-options ", "
+
(format "%s\n" title)
- (org-html-close-tag "meta" "name=\"generator\" content=\"Org mode\"" info)
- "\n"
- (and (org-string-nw-p author)
- (concat
- (org-html-close-tag "meta"
- (format "name=\"author\" content=\"%s\""
-
Re: ob-haskell
Hi Lawrence,
This isn't a method for official language support, but I've had success with
entirely unsupported REPLs and ob-screen. A .screenrc can launch the REPL, and
then Org ob-screen just sends each line to the buffer. It works OK for me.
-k.
On 2021-01-02 at 13:44 -08, Lawrence Bottorff wrote...
> I recently wimped out of trying to update ob-haskell as an official
> maintainer, but I'd eventually like to get back to it -- *after *I get
> some base understanding of what Haskell is (Zeno's paradox-land?) and
> how the ghci works. Basically, the ghci is what it is -- tautological,
> but true. And that means when ob-haskell does nothing but dump the
> contents of a babel code block into ghci, it's no better than if the
> user had typed in into the REPL line-by-line. A quick run-down:
>
> :set +m supposedly alerts ghci that a multi-line expression is coming, will
> come; but typically, it doesn't infer this very well.
>
> Enclosing code in :{ ... :} is fairly good -- again you can type this in at
> the REPL prompt and see how it works -- however, there are gotchas.
>
> a plain block:
>
> #+begin_src haskell
> ...code...
> #+end_src
>
> is okay when you only have a one-liner to evaluate. But again, ob-haskell
> seems to do nothing but take the block contents and dump it to the ghci
> REPL as though the user had typed it in line-by-line, Enter, Enter...
>
> What would be nice is if a C-c C-c inside a block could somehow act as
> though the ghci were being sent a regular *.hs buffer in haskell-mode --
> and that, of course, cumulatively. C-' creates a decent haskell-mode
> environment, BTW, so some form of a babel block to haskell-mode connection
> does exist
>
> So am I on the right track? It's obvious at this point raw dumps into the
> REPL aren't optimal, i.e., are fraught. What is, e.g., geiser doing
> that ob-haskell isn't?
>
> LB
>
> PS: Eventually, I'll try to glean some hints from the Jupyter Haskell
> effort.
>
> PPS: GHCI User's Guide
>
> doesn't
> really tell me anything other than yes, ob-haskell is raw-dumping into an
> environment that isn't designed to play nice with babel.
Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
Juan Manuel Macías writes: > Thank you very much for your response and your comments. Seriously, thanks for the patch. I think the ML is usually a bit more responsive, but it seems to be a bit quiet at the moment. > I agree to name "Insert, include, etc." the attribute to include > arbitrary LaTeX code, better than "options". Glad my feedback seems to have gone down well :). If the only likely use of this is adjusting the font, perhaps for the sake of consistency we can match the behaviour of tables, which take a :font LaTeX attribute? > Of course, I can add the necessary documentation to the files you tell > me. As I am new to submitting patches, I don't really know how to > proceed: do I have to send you the new version of the patch, with the > documentation? Should I send a new email with all of it to this list? Thanks for asking. Sometimes it seems the maintainers take the trouble of adding an ORG-NEWS entry or minor touching ups to the patch, but I think it's nice to leave as little for them to do as possible :) Announce changes in: etc/ORG-NEWS Document new/different behaviour in: doc/org-manual.org I think Markup for /Rich Contents > Paragraphs/ may be the right place to add a description of this functionality --- verse blocks are discussed around line 10750. Regarding how patches on this ML work, this is what I've observed: - Initial version of patch submitted, with justification/explanation - Feedback may be given - Revisions of the patch are attached in replies to feedback - Process repeats until everyone's happy - Patch is merged i.e. it all tends to happen in the same thread. Hope this helps, Timothy.
Re: [PATCH] Enhance org-html--build-meta-info
On 2021-01-03, TEC wrote: > After considering the information passed to a meta info generation > function, I'm now in agreement with you that just passing `info' is the > most sensible way forward. Hi Timothy, great, thanks :-) > Attached is a (final?) set of patches, which is as described. The doc strings of org-html-meta-tags and org-html-meta-tags-default need to be updated, they still mention author and title. Also, please try checkdoc ;) Best wishes Jens smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
Hi Timothy, TEC writes: > Hi Juan, > > Thanks for your patch. > > This looks like a fairly sensible addition. Two comments from me: > > 1. I'm not sure that "options" is a good name for arbitrary LaTeX which >is included inside the verse block. Perhaps something like "insert" >or "include", etc. may be a better fit. > 2. It's considered generally nice to document features like this :) The >two documents which I'd think to note this in are ORG-NEWS and the >manual (docs/manual.org). Thank you very much for your response and your comments. I agree to name "Insert, include, etc." the attribute to include arbitrary LaTeX code, better than "options". Of course, I can add the necessary documentation to the files you tell me. As I am new to submitting patches, I don't really know how to proceed: do I have to send you the new version of the patch, with the documentation? Should I send a new email with all of it to this list? Best regards, Juan Manuel > All the best, > > Timothy. >
Re: [PATCH] A proposal to add LaTeX attributes to verse blocks
Hi Juan,
Thanks for your patch.
This looks like a fairly sensible addition. Two comments from me:
1. I'm not sure that "options" is a good name for arbitrary LaTeX which
is included inside the verse block. Perhaps something like "insert"
or "include", etc. may be a better fit.
2. It's considered generally nice to document features like this :) The
two documents which I'd think to note this in are ORG-NEWS and the
manual (docs/manual.org).
All the best,
Timothy.
Juan Manuel Macías writes:
> (Sorry, due to a mistake, the text of my message did not appear in my
> previous email)
>
> Hi,
>
> I would like to propose this patch to add some LaTeX attributes to the verse
> block,
> especially to be able to apply certain features from the verse.sty package,
> which is an
> extension (widely used in Humanities) of the standard LaTeX 'verse'
> environment.
>
> These attributes would be:
>
> - `:lines' to add verse numbers, according to any numbering sequence
> - `:center' to apply the optical centering of the poem, which is a
> typographic convention
> whereby a poem or a group of verses is centered on the page, taking the
> width of the
> longest verse as a reference. In fact, optical centering is the correct
> arrangement of
> verses in a document.
> - `:versewidth' which expects a text string that is the longest verse of the
> poem,
> required when applying the `:center' attribute.
>
> As I said, these three attributes require the LateX package verse.sty. A
> fourth `:options'
> attribute would be used to add arbitrary code within the verse environment.
>
> Consider this complete example with Shakespeare's first sonnet:
>
> #+begin_src org
> ,#+ATTR_LaTeX: :center t :options \small :lines 5
> ,#+ATTR_LaTeX: :versewidth Feed’st thy light’st flame with self-substantial
> fuel,
> ,#+begin_verse
> From fairest creatures we desire increase,
> That thereby beauty’s rose might never die,
> But as the riper should by time decrease,
> His tender heir mught bear his memeory:
> But thou, contracted to thine own bright eyes,
> Feed’st thy light’st flame with self-substantial fuel,
> Making a famine where abundance lies,
> Thyself thy foe, to thy sweet self too cruel.
> Thou that art now the world’s fresh ornament
> And only herald to the gaudy spring,
> Within thine own bud buriest thy content
> And, tender churl, makest waste in niggarding.
> Pity the world, or else this glutton be,
> To eat the world’s due, by the grave and thee.
> ,#+end_verse
> #+end_src
>
> when exporting to LaTeX we get:
>
> #+begin_src latex
> \settowidth{\versewidth}{Feed’st thy light’st flame with self-substantial
> fuel,}
> \begin{verse}[\versewidth]
> \poemlines{5}
> \small
> From fairest creatures we desire increase,\\
> That thereby beauty’s rose might never die,\\
> But as the riper should by time decrease,\\
> His tender heir mught bear his memeory:\\
> But thou, contracted to thine own bright eyes,\\
> Feed’st thy light’st flame with self-substantial fuel,\\
> Making a famine where abundance lies,\\
> Thyself thy foe, to thy sweet self too cruel.\\
> Thou that art now the world’s fresh ornament\\
> And only herald to the gaudy spring,\\
> Within thine own bud buriest thy content\\
> And, tender churl, makest waste in niggarding.\\
> Pity the world, or else this glutton be,\\
> To eat the world’s due, by the grave and thee.\\
> \end{verse}
> #+end_src
>
> In an attached image I send a screenshot with the typographic result
>
> And finally, this is the patch I would propose
>
> #+begin_src diff
> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index 2a14b25d5..bc6b64e78 100644
> --- a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -3506,6 +3506,16 @@ channel."
>"Transcode a VERSE-BLOCK element from Org to LaTeX.
> CONTENTS is verse block contents. INFO is a plist holding
> contextual information."
> +(let*
> + ((lin (org-export-read-attribute :attr_latex verse-block :lines))
> + (opt (org-export-read-attribute :attr_latex verse-block :options))
> + (cent (org-export-read-attribute :attr_latex verse-block :center))
> + (attr (concat
> + (if cent "[\\versewidth]" "")
> + (if lin (format "\n\\poemlines{%s}" lin) "")
> + (if opt (format "\n%s" opt) "")))
> + (versewidth (org-export-read-attribute :attr_latex verse-block
> :versewidth))
> + (vwidth-attr (if versewidth (format
> "\\settowidth{\\versewidth}{%s}\n" versewidth) "")))
>(concat
> (org-latex--wrap-label
> verse-block
> @@ -3513,7 +3523,9 @@ contextual information."
> ;; character and change each white space at beginning of a line
> ;; into a space of 1 em. Also change each blank line with
> ;; a vertical space of 1 em.
> -(format "\\begin{verse}\n%s\\end{verse}"
> +(format "%s\\begin{verse}%s\n%s\\end{verse}"
> + vwidth-attr
> + attr
> (replace-regexp-in-string
>
Re: [patch] A proposal to add LaTeX attributes to verse blocks
Hi Juan, Since you've resent this in a second email, let's discuss this patch there. As such, I'm marking this patch as closed. -- Timothy.
Re: [PATCH] ox-md.el/preserve radio target hyperlink
Hi turbo. As this appears to be an exact duplicate of your other email, I'm going to mark this as closed and hope that any/all conversation on your patch happens there. -- Timothy
Re: [PATCH] ox-md.el/markdown-hyperlink
Thanks for the patch turbo. I was able to test this with a simple Org file, and both observed the issue with radio targets in generated markdown files, and observed the patch fixing it, as intended. -- Timothy turbo.c...@clovermail.net writes: > exporting to markdown loses radio target hyperlinks.
Re: [PATCH] Async session eval (2nd attempt)
Hi Jack,
I love the look of this! Thanks for submitting a patch.
Sorry it's taken so long for someone to take a look at it, I think a lot
of the 'main' Org people have been pretty busy over the last few months.
I just tried to give this a shot.
First up, I had to remove the ORG-NEWS part of the patch to be able to
provide it. It would be nice if you could update the patch so this
applies cleanly.
#+begin_example
error: patch failed: etc/ORG-NEWS:88
error: etc/ORG-NEWS: patch does not apply
#+end_example
To test this, after applying your patch (with ORG-NEWS removed), I
started emacs -Q, loaded Org, and opened a new file.
I was initially unable to get this to seem to work, until I changed the
:results type to "output".
See a excerpt from my test file below:
- excerpt start -
#+begin_src python :async :session blah :results output
from time import sleep
a=2
sleep(2)
print("Hi")
#+end_src
#+RESULTS:
: Hi
#+begin_src python :async :session blah
return(a)
#+end_src
#+RESULTS:
: /tmp/babel-62cQRX/python-EfJ4o4
#+begin_src python :async :session blah :results output
print(a)
#+end_src
#+RESULTS:
: 2
- excerpt end -
I'm surprised this didn't work with the non-output block though.
Other than this, I'm rather happy to see that when I tried to execute
two long running blocks at once, the second one was not executed until
the first completed :)
Finally, I see that this requires :session to be set in order to work.
Might it be possible to have this work for non-session blocks too? It
seems odd that what I'd imagine is the harder case (session blocks) is
supported, but one-shot (non-session) blocks aren't.
Thanks again for your work, and I look forward to seeing what else you
have in the future!
--
Timothy
p.s. After this is merged, it would be great to see support for other
languages grow :)
Jack Kamm writes:
> This patch adds asynchronous evaluation for session blocks in
> Python. It also adds functionality to implement async session eval for
> other languages using ob-comint.el.
>
> To test the attached patch, add ":async" to a Python session block
> with a long computation (or "time.sleep") in it. Upon evaluation, your
> Emacs won't freeze to wait for the result -- instead, a placeholder
> will be inserted, and replaced with the true result when it's ready.
>
> I'll note how this is different from some related projects. ob-async
> implements asynchronous evaluation for Babel, but it doesn't work with
> sessions. emacs-jupyter, ein, and ob-ipython all implement
> asynchronous session evaluation, but only for Jupyter kernels. Jupyter
> is great for some cases, but sometimes I prefer to use the built-in
> org-babel languages without jupyter.
>
> The new functionality is mainly implemented in
> `org-babel-comint-async-filter', which I've defined in ob-comint.el,
> and added as a hook to `comint-output-filter-functions'. Whenever new
> output is added to the comint buffer, the filter scans for an
> indicator token (this is inspired by
> `org-babel-comint-with-output'). Upon encountering the token, the
> filter uses a regular expression to extract a UUID or temp-file
> associated with the result, then searches for the appropriate location
> to add the result to.
>
> This is my 2nd attempt at this patch [0]. I have also ported it to an
> external package [1], but would like to have this functionality in Org
> proper, to permit better code reuse between async and sync
> implementations. The external package also includes an R
> implementation that I regularly use, as well as a Ruby implementation,
> but I've left these out to keep this initial patch smaller, and also I
> need to confirm copyright assignment on the Ruby implementation which
> was externally contributed.
>
> [0]
> https://orgmode.org/list/87muj04xim.fsf@jaheira.i-did-not-set--mail-host-address--so-tickle-me/
> [1] https://github.com/jackkamm/ob-session-async
Problems with attachment links in exported files
Hi everyone! I've had a trouble with attachment type link on exporting. I configured org-attach directory and using org-id and it works great on emacs, all those links work great. I can see any attach linked on org notes, but in exported files all those links point to local directory instead of the right attached folder. I read this article ( https://vxlabs.com/2020/07/25/emacs-lisp-function-convert-attachment-to-file/) which talks about that "org-attach-export-link" function will be removed. I've tried to convert attachment to file links, and it works fine. But I'd prefer to use attachment links instead of converting them. I also read this thread ( https://lists.libreplanet.org/archive/html/emacs-orgmode/2020-02/msg00784.html), but I'm quite sure if all these changes all actually implemented on org-mode. I tried to use (add-hook 'org-export-before-parsing-hook 'org-attach-expand-links) And it works except for inline images, but I don't understand why is not on org-mode repository code. Thanks you in advance!. Best regards! P.D.: I also tried to look up more information about this problem on this list, I couldn't find anything on the list searcher. https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=attachment=Search%21=emacs-orgmode=20=normal=score
