vertical spacing between lines in a list at odt-export
Dear All,
is there a way to modify the vertical spacing between lines in a list
when exporting to ODT?
For PDF-export
#+LATEX_HEADER: \usepackage{enumitem} together with
#+LATEX_HEADER: \setlist{noitemsep} or
#+ATTR_LATEX: :options [noitemsep]
work, but I did not find any hint regarding ODT-export.
best regards,
Heinz
Re: ISSUE: Unable to resolve link (html export)
Hello, Anthony Carrico writes: > * Steps to reproduce: > > 1. Create a file called test.org: > > #+TITLE: test.org > > 2. Create a file called test2.org: > > #+TITLE: test2.org > [[file:test.org::+TITLE: test][test]] > > 3. Export C-c C-e h H > > * Expected result: > > An html buffer > > * Actual result: > > Unable to resolve link: "No match for fuzzy expression: +TITLE: test" > > * Additional data > > The link was created by going to the first line of test.org and hitting > C-c l, then the second line of test2.org and hitting C-c C-l. > > * Work around > > It seems like changing the link to: > > [[file:test.org::#+TITLE: test][test]] > > allows the export to succeed. On the other hand, the original link works > fine internally. This leads me to suspect that export is using different > code to follow links, but also that the insert link code is buggy, > skipping the pound symbol. The pound character has a special meaning in links. It denotes custom IDs. Here, [[file:test.org::#+TITLE: test]] means you're looking for a headline with the CUSTOM_ID property set to "+TITLE: test" in the file "test.org" Therefore, it is automatically removed in another context, e.g., in text search. However, the export process doesn't resolve text searches. If you want to link to a specific part of the text, you can use a target. Regards, -- Nicolas Goaziou
Re: [bug] args out of range upon meta-return in body of list item
Hello, Kyle Meyer writes: > The change doesn't make any tests fail, but I'd need to look into the > code a bit more to be comfortable with the change. (For instance, is > the fact that there isn't a match here a sign that something's going > wrong upstream?) Yes, the problem lies in `org-list-insert-item'. I pushed a fix and a test for that. Regards, -- Nicolas Goaziou
Re: [PATCH] improve ol-man.el with occur searching
Hello, "numbch...@gmail.com" writes: > With this patch, ol-man.el link type can be a link like this: > ```org > [[man:grep::--extended-regexp][grep --extended-regexp]] > ``` > Occur will auto search "--extended-regexp" string in man page buffer. Thanks. > +PATH should be a topic that can be thrown at the man command. > +If PATH contains extra ::STRING which will use `occur' to search > +matched strings in man buffer." > + (string-match "\\(.*?\\)\\(?:::\\(.*\\)\\)?$" path) > + (let* ((command (match-string 1 path)) > + (search (match-string 2 path))) > +(funcall org-man-command command) > +(with-current-buffer (concat "*Man " command "*") This should only be called if search is non-empty. > + (occur search Why occur? Org uses `search-forward' for [[foo.org::text]] text links, and uses `occur' with [[foo.org::/text/]] links. Wouldn't it be more idiomatic to use a regular text search here? Regards, -- Nicolas Goaziou
Re: Bug: links to filename containing word "loops" fail to export
Hello, Jarmo Hurri writes: > * Links to files containing the word ~loops~ are not exported > ** What is the problem? >It seems that if a link to a file contains the word ~loops~, >it is not exported at all. > ** How to replicate >1. Save this org into file =org-loops-in-link.org= >2. Save the following elisp into =minimal-org.el=, replacing the > location of org mode with your path: > > #+begin_src elisp >(add-to-list 'load-path (expand-file-name "~/src/org-mode/lisp")) >(add-to-list 'load-path (expand-file-name > "~/src/org-mode/contrib/lisp" t)) > #+end_src > >3. Open this file with > > #+begin_src sh > emacs -Q -l minimal-org.el org-loops-in-link.org > #+end_src > >4. Export to latex as a PDF file and open (C-c C-e l o), observing > missing items when the list below is exported: > - [[file:loopy.org]] > - [[file:loops.org]] > - [[file:loopz.org]] > - [[file:some-loops.org]] > - [[file:some-loopz.org]] Fun bug. This should be fixed (make sure to start from the new value for org-latex-inline-image-rules if you customized it). Thank you. Regards, -- Nicolas Goaziou
Re: Bug: links to filename containing word "loops" fail to export
Nicolas Goaziou writes: >> * Links to files containing the word ~loops~ are not exported > > Fun bug. Indeed! Had to take a second cup of coffee before I believed my eyes. > This should be fixed Seems to be working now, thank you very much. All the best, and stay safe. Jarmo
Re: Strange problem loading org features in Emacs 27.1
> On Aug 16, 2020, at 2:00 AM, Axel Kielhorn wrote: > > Hello Carlo, > >> Am 16.08.2020 um 05:31 schrieb Carlo Tambuatco : >> >> I have org-20200803 package installed in my elpa folder. >> >> Here’s the message emacs gives me after loading my org-init.el file >> initializing org mode in >> emacs 27.1: >> >> Problems while trying to load feature ‘org-bbdb’ >> ... >> Problems while trying to load feature ‘org-rmail’ >> >> The offending line of code in the org-init.el file is: >> >> ;;;Customize org modules >> (setq org-modules '(org-bbdb >> org-gnus >> org-habit >> org-irc >> org-mouse >> org-crypt >> org-protocol >> org-w3m >> org-bibtex >> org-docview >> org-info >> org-mhe >> org-rmail)) >> >> (eval-after-load 'org >> '(org-load-modules-maybe t)) >> >> I don’t know enough about how org mode is organized to know what is going on >> here, but I just >> noticed this happening after upgrading to emacs-27. >> >> What do I do about this problem? Emacs isn’t giving me enough information to >> give me an idea >> of what is going on here. > > These files have been renamed in March 2019. > > With Emacs 26 the file from a previous org version supplied with Emacs have > been used. > Emacs 27.1 has a more recent version of org-mode. > > The easiest way to fix this is to rename the files in your org-init.el file. > > Of course you can use the customize interface as well. > > Greetings > Axel > > > Thanks. What was the reason for the name change?
Re: [SUSPECTED SPAM]New package: Org Pandoc Import
I'll have to take a closer look, but at a glance I think I'll be using this every day from now on. I interact with three wiki formats frequently at work. I'd written a few helpers to convert tables back and forth but mostly resort to writing in those markups or exporting to markdown and hand converting. This will be a big help. Thanks! On Sat, Aug 15, 2020, 3:30 PM TEC wrote: > Hi Everyone, > > I've just pushed the initial version of a package I think is pretty nifty > (no > bias here ;) and thought it might me nice to mention it to the mailing > list. > > https://github.com/tecosaur/org-pandoc-import > > This leverages Pandoc to reduce my interaction with other formats. > Hopefully > it's of interest to a few of you :) > > Enjoy! > > Timothy. > >
Re: Bug: org-agenda-todo applied to wrong line item [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]
> Using Emacs 26.3 with a vanilla configuration and the Org repo checked > out at 5e4542d69 (the commit reported in the subject line), I didn't see > the behavior you describe. With point at the end of the agenda line for > A, the state was changed for A. I think that may happen when you have agenda filter active and an entry hidden by filter is between the current and next line. Best, Ihor Kyle Meyer writes: > Dinnyés Dániel writes: > >> While in the Org Agenda, and navigating to the end of line for a given item >> (assuming more than one todo items), and calling org-agenda-todo (with >> keybindings t, or C-c C-t)... this result in the call being applied to the >> next line item, instead of the one the cursor is on. >> >> This only happens when the cursor is at the end of the line. >> >> I would consider this to be a bug. > > I tried using the following content as the agenda file: > > * TODO A > * TODO B > > Using Emacs 26.3 with a vanilla configuration and the Org repo checked > out at 5e4542d69 (the commit reported in the subject line), I didn't see > the behavior you describe. With point at the end of the agenda line for > A, the state was changed for A. > > I also can't trigger the behavior with the master branch checked out.
Re: keep org drawers visible
> I realise the above is none too clear. I can use showeverything in > STARTUP of course and this does indeed open the drawers. However the > drawers close and remain closed after multiple uses of -. > Therefore my question is how can I again reach the showeverything status > without closing down the file and re-opening it? Take a look at default org-cycle-hook value. You can remove org-cycle-hide-drawers from there. Best, Ihor Colin Baxter writes: >> Colin Baxter writes: > > > Hello, > > > Property drawers remaining invisible even when I use - > > drives me nuts. I know about M-x org-hide-drawer-toggle but > > how do I keep the drawers open all the time without having to > > toggle? I work on the basis that I want to see what I write - if I > > didn't then I wouldn't have written it. > > I realise the above is none too clear. I can use showeverything in > STARTUP of course and this does indeed open the drawers. However the > drawers close and remain closed after multiple uses of -. > Therefore my question is how can I again reach the showeverything status > without closing down the file and re-opening it? > > Colin Baxter.
Re: Strange problem loading org features in Emacs 27.1
I think they are all org link related files, hence the change to the ol-prefix. On Sun, Aug 16, 2020 at 7:27 AM Carlo Tambuatco wrote: > > > > > > On Aug 16, 2020, at 2:00 AM, Axel Kielhorn > wrote: > > > > > > Hello Carlo, > > > > > >> Am 16.08.2020 um 05:31 schrieb Carlo Tambuatco : > > >> > > >> I have org-20200803 package installed in my elpa folder. > > >> > > >> Here’s the message emacs gives me after loading my org-init.el file > initializing org mode in > > >> emacs 27.1: > > >> > > >> Problems while trying to load feature ‘org-bbdb’ > > >> ... > > >> Problems while trying to load feature ‘org-rmail’ > > >> > > >> The offending line of code in the org-init.el file is: > > >> > > >> ;;;Customize org modules > > >> (setq org-modules '(org-bbdb > > >> org-gnus > > >> org-habit > > >> org-irc > > >> org-mouse > > >> org-crypt > > >> org-protocol > > >> org-w3m > > >> org-bibtex > > >> org-docview > > >> org-info > > >> org-mhe > > >> org-rmail)) > > >> > > >> (eval-after-load 'org > > >> '(org-load-modules-maybe t)) > > >> > > >> I don’t know enough about how org mode is organized to know what is > going on here, but I just > > >> noticed this happening after upgrading to emacs-27. > > >> > > >> What do I do about this problem? Emacs isn’t giving me enough > information to give me an idea > > >> of what is going on here. > > > > > > These files have been renamed in March 2019. > > > > > > With Emacs 26 the file from a previous org version supplied with Emacs > have been used. > > > Emacs 27.1 has a more recent version of org-mode. > > > > > > The easiest way to fix this is to rename the files in your org-init.el > file. > > > > > > Of course you can use the customize interface as well. > > > > > > Greetings > > > Axel > > > > > > > > > > > > > > > Thanks. > > > > What was the reason for the name change? > > > > > > > > -- John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: keep org drawers visible
> Ihor Radchenko writes: >> I realise the above is none too clear. I can use showeverything >> in STARTUP of course and this does indeed open the >> drawers. However the drawers close and remain closed after >> multiple uses of -. Therefore my question is how can >> I again reach the showeverything status without closing down the >> file and re-opening it? > Take a look at default org-cycle-hook value. You can remove > org-cycle-hide-drawers from there. Thanks. Your suggestion led to where I should have looked at the beginning. I've found that "C-u C-u C-u" as a prefix to gives me immediately what I want. I'll look to modify the org-cycle-hook at a quieter time later. Thanks again. Best wishes, Colin.
Re: [SUSPECTED SPAM]New package: Org Pandoc Import
ian martins writes: I'll have to take a closer look, but at a glance I think I'll be using this every day from now on. I interact with three wiki formats frequently at work. I'd written a few helpers to convert tables back and forth but mostly resort to writing in those markups or exporting to markdown and hand converting. This will be a big help. Thanks! Fantastic to hear! If you become interested in improving the conversion between formats, please PR improvements. The extension currently has two entry points for import to org + pre-processing by calling an elisp function with the file of interest (see ./preprocessors) + lua filters (see ./filters) Then export is just calling any old elisp function you like :) All the best, Timothy.
Re: Bug: org-agenda-todo applied to wrong line item [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]
I have tried reproducing it with a minimal example, and this seems to work
for me:
* FOO
** TODO baz1
SCHEDULED: <2020-08-16 Sun>
some text
* BAR
** TODO baz2
SCHEDULED: <2020-08-16 Sun>
*** DONE baz3
SCHEDULED: <2020-08-16 Sun>
*** TODO baz4
SCHEDULED: <2020-08-16 Sun>
When in the agenda, on the front line of item baz, setting it to DONE state
works fine.
OTOH, when going to the end of the line on the item baz, trying to set it
to DONE results in the error message:
TODO state change from TODO to DONE blocked (by "TODO baz4")
Also, I have (org-enforce-todo-dependencies t), which causes the blocking,
and (org-agenda-dim-blocked-tasks (quote invisible)), which hides baz2 from
the agenda... because of this baz1 is followed directly by baz4 in my
agenda window.
Just for completeness, this my lengthy org configuration:
(use-package org
:init
(defun org-archive-done-tasks ()
"Archive all DONE and CANCELED tasks in the subtree of the current
entry"
(interactive)
(org-map-entries
(lambda ()
(org-archive-subtree)
(setq org-map-continue-from (outline-previous-heading)))
"//DONE|CANCELED" 'agenda))
:bind
(("C-c a" . org-agenda)
("C-c k" . org-capture)
:map org-mode-map
("C-c H" . org-archive-done-tasks)
("C-c e" . org-babel-execute-src-block))
:hook
(text-mode . visual-line-mode)
:config
(custom-set-variables
'(org-agenda-span 'day)
'(org-startup-indented t)
'(org-startup-folded nil)
'(org-directory "~/Workspace/org/")
'(org-agenda-files (list org-directory))
'(org-archive-location "archives.org::datetree/* %s")
'(org-agenda-diary-file (concat org-directory "diary.org"))
'(org-agenda-include-diary t)
'(org-deadline-warning-days 7)
'(org-agenda-skip-deadline-prewarning-if-scheduled 'pre-scheduled)
'(org-agenda-skip-scheduled-if-deadline-is-shown t)
'(org-agenda-skip-scheduled-if-done t)
'(org-agenda-todo-ignore-scheduled 'future)
'(org-agenda-tags-todo-honor-ignore-options t)
;; set SCHEDULED and DEADLINE leaders in agenda view
'(org-agenda-deadline-leaders (quote ("Deadline! " "In %d days: " "Late
%d days: ")))
'(org-agenda-scheduled-leaders (quote ("Scheduled! " "For %d days: ")))
'(org-agenda-window-setup 'only-window)
'(org-todo-keywords
(quote ((sequence "TODO(t!)" "ONGOING(o!)" "WAITING(w@)" "|" "DONE(d@)"
"CANCELED(c@)"
'(org-todo-keyword-faces
(quote (("WAITING" . "purple")
("ONGOING" . "orange")
("CANCELED" . "firebrick"
;; set ARCHIVE tag when todo state is set to CANCELED, and remove when
reset to TODO
`(org-todo-state-tags-triggers
(quote
((todo . ((,org-archive-tag . nil)))
("CANCELED" . ((,org-archive-tag . t))
'(org-tag-persistent-alist
'(("TARGET" . ?t)))
'(org-tags-exclude-from-inheritance (quote ("TARGET")))
;; REFILE BEHAVIOUR
'(org-refile-targets
'((nil . (:level . 1))
(nil . (:tag . "TARGET"
'(org-refile-use-outline-path t)
'(org-goto-interface 'outline-path-completion)
'(org-outline-path-complete-in-steps t)
;; prefer in-steps that ido for refile completion
;; '(org-completion-use-ido t)
'(org-reverse-note-order t)
;; LOGGING
;; todo state changes should be logged into drawer
'(org-log-into-drawer t)
;; log when schedule or deadline changes
'(org-log-redeadline (quote time))
'(org-log-reschedule (quote time))
;;'(org-log-refile (quote time)) ; logs even when refiled during capture
;; PRIORITIES
'(org-priority-start-cycle-with-default t)
'(org-default-priority 70)
'(org-lowest-priority 70)
'(org-highest-priority 65)
'(org-agenda-sorting-strategy
'((agenda time-up todo-state-down priority-down)
(todo category-up priority-down)
(tags category-up priority-down)
(search category-up)))
;; DEPENDENCIES
'(org-enforce-todo-dependencies t)
'(org-enforce-todo-checkbox-dependencies t)
'(org-agenda-dim-blocked-tasks (quote invisible))
;; CUSTOM COMMANDS
'(org-agenda-custom-commands
'(("c" . "Custom commands")
("cb" "Backlog (tasks not scheduled)" todo "TODO"
((org-agenda-skip-function
'(org-agenda-skip-entry-if 'scheduled
("cc" . "Filter tasks by CATEGORY")
("cci" "INBOX tasks"
((alltodo ""))
((org-agenda-category-filter-preset '("+INBOX"
("ccf" "INFRA tasks"
((alltodo ""))
((org-agenda-category-filter-preset '("+INFRA"
("ccr" "ROLES tasks"
((alltodo ""))
((org-agenda-category-filter-preset '("+ROLES"))
;; CAPTURE TEMPLATES
'(org-capture-templates
(quote
(("t" "Task")
("tt" "Task (Scheduled)" entry
(file+headline "tasks.org" "INBOX")
"* TODO %^{Title}\nSCHEDULED: %t\n%?")
("td" "Task (Scheduled, with Deadline)" entry
(file+headline "tasks.org" "INBOX")
"* TODO %^{Title}\nSCHEDULED: %^{Schedule}t DEADLINE: %^{Deadline}t\n%?")
("e" "Event")
("et" "Event (with single datetime)" entry
(file+hea
Re: Bug: org-agenda-todo applied to wrong line item [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]
Made some corrections in the text below (marked with red).
Also, removed the unnecessary "some text" from the body of baz1 item, as
the issue can reproduce without it.
On Sun, 16 Aug 2020 at 16:01, Dinnyés Dániel wrote:
> I have tried reproducing it with a minimal example, and this works for me:
>
> * FOO
> ** TODO baz1
> SCHEDULED: <2020-08-16 Sun>
>
>
* BAR
> ** TODO baz2
> SCHEDULED: <2020-08-16 Sun>
> *** DONE baz3
> SCHEDULED: <2020-08-16 Sun>
> *** TODO baz4
> SCHEDULED: <2020-08-16 Sun>
>
> When in the agenda, on the front line of item baz1, setting it to DONE
> state works fine.
> OTOH, when going to the end of the line on the item baz1, trying to set
> it to DONE results in the error message:
> TODO state change from TODO to DONE blocked (by "TODO baz4")
>
>
Also, I have (org-enforce-todo-dependencies t), which causes the blocking,
> and (org-agenda-dim-blocked-tasks (quote invisible)), which hides baz2
> from the agenda... because of this baz1 is followed directly by baz4 in
> my agenda window.
>
> Since baz4 is not a direct / transitive dependency to baz1, this blocking
> shouldn't happen.
>
I assume this happening has something to do with their closeness in the
> agenda ordering, and the cursor position.
>
Maybe the org-agenda-todo function somehow gets "confused" by running it at
> the end of the line in the agenda.
>
Just for completeness, this is a snapshot of my lengthy org configuration:
> (use-package org
> :init
> (defun org-archive-done-tasks ()
> "Archive all DONE and CANCELED tasks in the subtree of the current
> entry"
> (interactive)
> (org-map-entries
> (lambda ()
>(org-archive-subtree)
>(setq org-map-continue-from (outline-previous-heading)))
> "//DONE|CANCELED" 'agenda))
> :bind
> (("C-c a" . org-agenda)
>("C-c k" . org-capture)
>:map org-mode-map
>("C-c H" . org-archive-done-tasks)
>("C-c e" . org-babel-execute-src-block))
> :hook
> (text-mode . visual-line-mode)
> :config
> (custom-set-variables
>'(org-agenda-span 'day)
>'(org-startup-indented t)
>'(org-startup-folded nil)
>'(org-directory "~/Workspace/org/")
>'(org-agenda-files (list org-directory))
>'(org-archive-location "archives.org::datetree/* %s")
>'(org-agenda-diary-file (concat org-directory "diary.org"))
>'(org-agenda-include-diary t)
>'(org-deadline-warning-days 7)
>'(org-agenda-skip-deadline-prewarning-if-scheduled 'pre-scheduled)
>'(org-agenda-skip-scheduled-if-deadline-is-shown t)
>'(org-agenda-skip-scheduled-if-done t)
>'(org-agenda-todo-ignore-scheduled 'future)
>'(org-agenda-tags-todo-honor-ignore-options t)
>;; set SCHEDULED and DEADLINE leaders in agenda view
>'(org-agenda-deadline-leaders (quote ("Deadline! " "In %d days: "
> "Late %d days: ")))
>'(org-agenda-scheduled-leaders (quote ("Scheduled! " "For %d days: ")))
>'(org-agenda-window-setup 'only-window)
>'(org-todo-keywords
> (quote ((sequence "TODO(t!)" "ONGOING(o!)" "WAITING(w@)" "|" "DONE(d@)"
> "CANCELED(c@)"
>'(org-todo-keyword-faces
> (quote (("WAITING" . "purple")
> ("ONGOING" . "orange")
> ("CANCELED" . "firebrick"
>;; set ARCHIVE tag when todo state is set to CANCELED, and remove when
> reset to TODO
>`(org-todo-state-tags-triggers
> (quote
> ((todo . ((,org-archive-tag . nil)))
>("CANCELED" . ((,org-archive-tag . t))
>'(org-tag-persistent-alist
> '(("TARGET" . ?t)))
>'(org-tags-exclude-from-inheritance (quote ("TARGET")))
>;; REFILE BEHAVIOUR
>'(org-refile-targets
> '((nil . (:level . 1))
>(nil . (:tag . "TARGET"
>'(org-refile-use-outline-path t)
>'(org-goto-interface 'outline-path-completion)
>'(org-outline-path-complete-in-steps t)
>;; prefer in-steps that ido for refile completion
>;; '(org-completion-use-ido t)
>'(org-reverse-note-order t)
>
>;; LOGGING
>;; todo state changes should be logged into drawer
>'(org-log-into-drawer t)
>;; log when schedule or deadline changes
>'(org-log-redeadline (quote time))
>'(org-log-reschedule (quote time))
>;;'(org-log-refile (quote time)) ; logs even when refiled during capture
>
>;; PRIORITIES
>'(org-priority-start-cycle-with-default t)
>'(org-default-priority 70)
>'(org-lowest-priority 70)
>'(org-highest-priority 65)
>'(org-agenda-sorting-strategy
> '((agenda time-up todo-state-down priority-down)
>(todo category-up priority-down)
>(tags category-up priority-down)
>(search category-up)))
>
>;; DEPENDENCIES
>'(org-enforce-todo-dependencies t)
>'(org-enforce-todo-checkbox-dependencies t)
>'(org-agenda-dim-blocked-tasks (quote invisible))
>
>;; CUSTOM COMMANDS
>'(org-agenda-custom-commands
> '(("c" . "Custom commands")
>("cb" "Backlog (tasks not scheduled)" todo "TODO"
> ((org-agenda-skip-function
> '(org-agenda-ski
Re: [bug] args out of range upon meta-return in body of list item
Nicolas Goaziou writes: > Yes, the problem lies in `org-list-insert-item'. I pushed a fix and > a test for that. Great. Thank you!
Re: [bug] args out of range upon meta-return in body of list item
thank you both. On 8/16/20, Kyle Meyer wrote: > Nicolas Goaziou writes: > >> Yes, the problem lies in `org-list-insert-item'. I pushed a fix and >> a test for that. > > Great. Thank you! > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: How to detect current in logbook drawer?
Ihor, thanks for your detailed help.
I followed your steps, the `elp` step, I confirmed `org-link-beautify` is
invoked and fall into an infinite loop.
```
org-link-beautify 11265 58.586412984 0.0052007468
```
And another step `debug-on-entry` on `org-link-beautify`,
`org-agenda-finalize`, `org-activate-links`. I have not got a stoppoint
backtrace on any of upper functions when org-agenda initializes. This is
weird, because I tested to use `debug-on-entry` on `org-agenda`. It can
popup a stoppoint backtrace.
I reviewed my org-link-beautify (
https://github.com/stardiviner/org-link-beautify) source code, I have not
use any regexp matching. I guess the function
`org-link-beautify--get-element` invoked `(org-element-context)` caused
this problem or other similar places. But I use `debug-on-entry` on
`org-element-context`. Still have not got stoppoint backtrace.
Need your more help. Sorry for disturbing you
[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter: @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/
On Sun, Aug 16, 2020 at 2:39 PM Ihor Radchenko wrote:
> > Your suggestion is very useful, I can see what function is invoked many
> > times. But still can't understand what's the cause.
>
> Looking at your CPU profiler report I can see that the slow part is
> happening while running org-agenda-finalize when agenda buffer is
> already populated. Most of time is taken by calling your function. I
> suspect that it is simply called many times (maybe infinite loop?).
>
> You may check the number of times your function is called using
>
> (require 'elp)
> (elp-instrument-function #'org-link-beautify)
> ;; run agenda
> ;; M-x elp-results
>
> Another suggestion would be invoking debug-on-entry for you function,
> for org-activate-links, and for org-agenda-finalize.
>
> Best,
> Ihor
>
>
>
>
> "numbch...@gmail.com" writes:
>
> > I tried use debug-on-entry on:
> > + org-agenda-list(nil)
> > - org-agenda-mode()
> > + org-agenda-set-mode-name()
> > - org-update-dblock
> > + org-dblock-write:clocktable
> >
> > But got no lucky, Then I followed your another suggestion, use profiler:
> >
> > I got a very big message log, (not suitable for paste in email, so I
> paste
> > it on Gist)
> >
> > - CPU profiler report: https://www.pastery.net/gststf/
> > - Memory profiler report: https://www.pastery.net/gststf+qzyxaf/#qzyxaf
> >
> > The very deepest call stacks seems the output format is not long enough,
> so
> > can't display.
> >
> > Your suggestion is very useful, I can see what function is invoked many
> > times. But still can't understand what's the cause.
> >
> > [stardiviner] GPG key ID: 47C32433
> > IRC(freeenode): stardiviner Twitter: @numbchild
> > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
> > Blog: http://stardiviner.github.io/
> >
> >
> > On Sat, Aug 15, 2020 at 2:02 PM Ihor Radchenko
> wrote:
> >
> >> >Here is the backtrace of "toggle-debug-on-quit" when I refresh
> org-agenda
> >> >but has long time suspend.
> >>
> >> That looks unreadable for me. Also, debug on quit may not show the
> >> problematic part depending on your luck.
> >>
> >> It would be easier to understand your problem if you provided the
> >> profiler report (M-x profiler-start ... M-x profiler-report).
> >> Then, you could debug-on-entry using the problematic part according to
> >> the profiler report.
> >>
> >> A blind guess - maybe you are modifying match data somewhere in your
> >> code. This might cause infinite loop in
> >>
> >> > (while (org-activate-links (point-max)) (goto-char (match-end 0)))
> >>
> >> Best,
> >> Ihor
> >>
> >> "numbch...@gmail.com" writes:
> >>
> >> > Thanks for replying, Ihor. I will look into this regexp.
> >> >
> >> > Here is the backtrace of "toggle-debug-on-quit" when I refresh
> org-agenda
> >> > but has long time suspend.
> >> >
> >> > ```
> >> > Debugger entered--Lisp error: (quit)
> >> >
> >> >
> >>
> re-search-forward("\\(\\[\\[\\(\\(?:[^][\\]\\|\\(?:\\)*[][]\\|+[^][]\\)+..."
> >> > 17651 t)
> >> > (while (re-search-forward org-link-any-re limit t) (let* ((start
> >> > (match-beginning 0)) (end (match-end 0)) (visible-start (or
> >> > (match-beginning 3) (match-beginning 2))) (visible-end (or (match-end
> 3)
> >> > (match-end 2))) (style (cond ((eq 60 (char-after start)) 'angle) ((eq
> 91
> >> > (char-after ...)) 'bracket) (t 'plain (if (and (memq style
> >> > org-highlight-links) (not (string-match-p
> org-element-paragraph-separate
> >> > (match-string 0))) (not (and (eq style 'plain) (let (...) (if ... ...
> >> > ...) (progn (let* ((link-object (save-excursion ... ...)) (link
> >> > (org-element-property :raw-link link-object)) (type
> (org-element-property
> >> > :type link-object)) (path (org-element-property :path link-object))
> >> > (propertie
Re: How to detect current in logbook drawer?
I figured an temporary workaround solution:
Use `(unless (memq major-mode org-link-beautify-exclude-modes) ...` in
`org-link-beautify` function to exclude `org-agenda-mode`.
But I still wonder what caused this problem.
[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter: @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/
On Mon, Aug 17, 2020 at 8:38 AM numbch...@gmail.com
wrote:
> Ihor, thanks for your detailed help.
> I followed your steps, the `elp` step, I confirmed `org-link-beautify` is
> invoked and fall into an infinite loop.
>
> ```
> org-link-beautify 11265 58.586412984 0.0052007468
> ```
>
> And another step `debug-on-entry` on `org-link-beautify`,
> `org-agenda-finalize`, `org-activate-links`. I have not got a stoppoint
> backtrace on any of upper functions when org-agenda initializes. This is
> weird, because I tested to use `debug-on-entry` on `org-agenda`. It can
> popup a stoppoint backtrace.
>
> I reviewed my org-link-beautify (
> https://github.com/stardiviner/org-link-beautify) source code, I have not
> use any regexp matching. I guess the function
> `org-link-beautify--get-element` invoked `(org-element-context)` caused
> this problem or other similar places. But I use `debug-on-entry` on
> `org-element-context`. Still have not got stoppoint backtrace.
>
> Need your more help. Sorry for disturbing you
>
> [stardiviner] GPG key ID: 47C32433
> IRC(freeenode): stardiviner Twitter: @numbchild
> Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
> Blog: http://stardiviner.github.io/
>
>
> On Sun, Aug 16, 2020 at 2:39 PM Ihor Radchenko wrote:
>
>> > Your suggestion is very useful, I can see what function is invoked many
>> > times. But still can't understand what's the cause.
>>
>> Looking at your CPU profiler report I can see that the slow part is
>> happening while running org-agenda-finalize when agenda buffer is
>> already populated. Most of time is taken by calling your function. I
>> suspect that it is simply called many times (maybe infinite loop?).
>>
>> You may check the number of times your function is called using
>>
>> (require 'elp)
>> (elp-instrument-function #'org-link-beautify)
>> ;; run agenda
>> ;; M-x elp-results
>>
>> Another suggestion would be invoking debug-on-entry for you function,
>> for org-activate-links, and for org-agenda-finalize.
>>
>> Best,
>> Ihor
>>
>>
>>
>>
>> "numbch...@gmail.com" writes:
>>
>> > I tried use debug-on-entry on:
>> > + org-agenda-list(nil)
>> > - org-agenda-mode()
>> > + org-agenda-set-mode-name()
>> > - org-update-dblock
>> > + org-dblock-write:clocktable
>> >
>> > But got no lucky, Then I followed your another suggestion, use profiler:
>> >
>> > I got a very big message log, (not suitable for paste in email, so I
>> paste
>> > it on Gist)
>> >
>> > - CPU profiler report: https://www.pastery.net/gststf/
>> > - Memory profiler report: https://www.pastery.net/gststf+qzyxaf/#qzyxaf
>> >
>> > The very deepest call stacks seems the output format is not long
>> enough, so
>> > can't display.
>> >
>> > Your suggestion is very useful, I can see what function is invoked many
>> > times. But still can't understand what's the cause.
>> >
>> > [stardiviner] GPG key ID: 47C32433
>> > IRC(freeenode): stardiviner Twitter: @numbchild
>> > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
>> > Blog: http://stardiviner.github.io/
>> >
>> >
>> > On Sat, Aug 15, 2020 at 2:02 PM Ihor Radchenko
>> wrote:
>> >
>> >> >Here is the backtrace of "toggle-debug-on-quit" when I refresh
>> org-agenda
>> >> >but has long time suspend.
>> >>
>> >> That looks unreadable for me. Also, debug on quit may not show the
>> >> problematic part depending on your luck.
>> >>
>> >> It would be easier to understand your problem if you provided the
>> >> profiler report (M-x profiler-start ... M-x profiler-report).
>> >> Then, you could debug-on-entry using the problematic part according to
>> >> the profiler report.
>> >>
>> >> A blind guess - maybe you are modifying match data somewhere in your
>> >> code. This might cause infinite loop in
>> >>
>> >> > (while (org-activate-links (point-max)) (goto-char (match-end 0)))
>> >>
>> >> Best,
>> >> Ihor
>> >>
>> >> "numbch...@gmail.com" writes:
>> >>
>> >> > Thanks for replying, Ihor. I will look into this regexp.
>> >> >
>> >> > Here is the backtrace of "toggle-debug-on-quit" when I refresh
>> org-agenda
>> >> > but has long time suspend.
>> >> >
>> >> > ```
>> >> > Debugger entered--Lisp error: (quit)
>> >> >
>> >> >
>> >>
>> re-search-forward("\\(\\[\\[\\(\\(?:[^][\\]\\|\\(?:\\)*[][]\\|+[^][]\\)+..."
>> >> > 17651 t)
>> >> > (while (re-search-forward org-link-any-re limit t) (let* ((start
>> >> > (match-beginning 0)) (end (match-end 0)) (vi
Re: How to detect current in logbook drawer?
> I reviewed my org-link-beautify ( > https://github.com/stardiviner/org-link-beautify) source code, I have not > use any regexp matching. I guess the function > `org-link-beautify--get-element` invoked `(org-element-context)` caused > this problem or other similar places. But I use `debug-on-entry` on > `org-element-context`. Still have not got stoppoint backtrace. Judging from source code of `org-element-context`, it does modify match data. You can probably send a bug (or patch) fixing this. All is needed is to wrap the code into `save-match-data`. For you package, you can simply wrap all the code in `org-link-beautify` into (save-match-data ... ). > And another step `debug-on-entry` on `org-link-beautify`, > `org-agenda-finalize`, `org-activate-links`. I have not got a stoppoint > backtrace on any of upper functions when org-agenda initializes. This is > weird, because I tested to use `debug-on-entry` on `org-agenda`. It can > popup a stoppoint backtrace. Strange. I had no problem with debugging `org-agenda-finalize` on my system. Best, Ihor "numbch...@gmail.com" writes: > Ihor, thanks for your detailed help. > I followed your steps, the `elp` step, I confirmed `org-link-beautify` is > invoked and fall into an infinite loop. > > ``` > org-link-beautify 11265 58.586412984 0.0052007468 > ``` > > And another step `debug-on-entry` on `org-link-beautify`, > `org-agenda-finalize`, `org-activate-links`. I have not got a stoppoint > backtrace on any of upper functions when org-agenda initializes. This is > weird, because I tested to use `debug-on-entry` on `org-agenda`. It can > popup a stoppoint backtrace. > > I reviewed my org-link-beautify ( > https://github.com/stardiviner/org-link-beautify) source code, I have not > use any regexp matching. I guess the function > `org-link-beautify--get-element` invoked `(org-element-context)` caused > this problem or other similar places. But I use `debug-on-entry` on > `org-element-context`. Still have not got stoppoint backtrace. > > Need your more help. Sorry for disturbing you > > [stardiviner] GPG key ID: 47C32433 > IRC(freeenode): stardiviner Twitter: @numbchild > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 > Blog: http://stardiviner.github.io/ > > > On Sun, Aug 16, 2020 at 2:39 PM Ihor Radchenko wrote: > >> > Your suggestion is very useful, I can see what function is invoked many >> > times. But still can't understand what's the cause. >> >> Looking at your CPU profiler report I can see that the slow part is >> happening while running org-agenda-finalize when agenda buffer is >> already populated. Most of time is taken by calling your function. I >> suspect that it is simply called many times (maybe infinite loop?). >> >> You may check the number of times your function is called using >> >> (require 'elp) >> (elp-instrument-function #'org-link-beautify) >> ;; run agenda >> ;; M-x elp-results >> >> Another suggestion would be invoking debug-on-entry for you function, >> for org-activate-links, and for org-agenda-finalize. >> >> Best, >> Ihor >> >> >> >> >> "numbch...@gmail.com" writes: >> >> > I tried use debug-on-entry on: >> > + org-agenda-list(nil) >> > - org-agenda-mode() >> > + org-agenda-set-mode-name() >> > - org-update-dblock >> > + org-dblock-write:clocktable >> > >> > But got no lucky, Then I followed your another suggestion, use profiler: >> > >> > I got a very big message log, (not suitable for paste in email, so I >> paste >> > it on Gist) >> > >> > - CPU profiler report: https://www.pastery.net/gststf/ >> > - Memory profiler report: https://www.pastery.net/gststf+qzyxaf/#qzyxaf >> > >> > The very deepest call stacks seems the output format is not long enough, >> so >> > can't display. >> > >> > Your suggestion is very useful, I can see what function is invoked many >> > times. But still can't understand what's the cause. >> > >> > [stardiviner] GPG key ID: 47C32433 >> > IRC(freeenode): stardiviner Twitter: @numbchild >> > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 >> > Blog: http://stardiviner.github.io/ >> > >> > >> > On Sat, Aug 15, 2020 at 2:02 PM Ihor Radchenko >> wrote: >> > >> >> >Here is the backtrace of "toggle-debug-on-quit" when I refresh >> org-agenda >> >> >but has long time suspend. >> >> >> >> That looks unreadable for me. Also, debug on quit may not show the >> >> problematic part depending on your luck. >> >> >> >> It would be easier to understand your problem if you provided the >> >> profiler report (M-x profiler-start ... M-x profiler-report). >> >> Then, you could debug-on-entry using the problematic part according to >> >> the profiler report. >> >> >> >> A blind guess - maybe you are modifying match data somewhere in your >> >> code. This might cause infinite loop in >> >> >> >> > (while (org-activate-links (point-max)) (goto-char (match-end 0))) >> >> >>
[BUG] The latest commit "f4687993c53a5339e" caused inline image preview try to convert PDF file link
RT. The latest commit "f4687993c53a5339e" added "pdf" file type into inline image rules. This caused org-toggle-inline-image try to convert large PDF into png images. Caused very long time suspend. [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/
Re: How to detect current in logbook drawer?
Now I added `save-match-data` in my org-link-beautify. Thanks for tips. Indeed. I will try this problem later and update here if got any news. At last, thanks for your helping. Really thanks. :) [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Mon, Aug 17, 2020 at 9:50 AM Ihor Radchenko wrote: > > I reviewed my org-link-beautify ( > > https://github.com/stardiviner/org-link-beautify) source code, I have > not > > use any regexp matching. I guess the function > > `org-link-beautify--get-element` invoked `(org-element-context)` caused > > this problem or other similar places. But I use `debug-on-entry` on > > `org-element-context`. Still have not got stoppoint backtrace. > > Judging from source code of `org-element-context`, it does modify match > data. You can probably send a bug (or patch) fixing this. All is needed > is to wrap the code into `save-match-data`. > > For you package, you can simply wrap all the code in `org-link-beautify` > into (save-match-data ... ). > > > And another step `debug-on-entry` on `org-link-beautify`, > > `org-agenda-finalize`, `org-activate-links`. I have not got a stoppoint > > backtrace on any of upper functions when org-agenda initializes. This is > > weird, because I tested to use `debug-on-entry` on `org-agenda`. It can > > popup a stoppoint backtrace. > > Strange. I had no problem with debugging `org-agenda-finalize` on my > system. > > Best, > Ihor > > > "numbch...@gmail.com" writes: > > > Ihor, thanks for your detailed help. > > I followed your steps, the `elp` step, I confirmed `org-link-beautify` is > > invoked and fall into an infinite loop. > > > > ``` > > org-link-beautify 11265 58.586412984 0.0052007468 > > ``` > > > > And another step `debug-on-entry` on `org-link-beautify`, > > `org-agenda-finalize`, `org-activate-links`. I have not got a stoppoint > > backtrace on any of upper functions when org-agenda initializes. This is > > weird, because I tested to use `debug-on-entry` on `org-agenda`. It can > > popup a stoppoint backtrace. > > > > I reviewed my org-link-beautify ( > > https://github.com/stardiviner/org-link-beautify) source code, I have > not > > use any regexp matching. I guess the function > > `org-link-beautify--get-element` invoked `(org-element-context)` caused > > this problem or other similar places. But I use `debug-on-entry` on > > `org-element-context`. Still have not got stoppoint backtrace. > > > > Need your more help. Sorry for disturbing you > > > > [stardiviner] GPG key ID: 47C32433 > > IRC(freeenode): stardiviner Twitter: @numbchild > > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 > > Blog: http://stardiviner.github.io/ > > > > > > On Sun, Aug 16, 2020 at 2:39 PM Ihor Radchenko > wrote: > > > >> > Your suggestion is very useful, I can see what function is invoked > many > >> > times. But still can't understand what's the cause. > >> > >> Looking at your CPU profiler report I can see that the slow part is > >> happening while running org-agenda-finalize when agenda buffer is > >> already populated. Most of time is taken by calling your function. I > >> suspect that it is simply called many times (maybe infinite loop?). > >> > >> You may check the number of times your function is called using > >> > >> (require 'elp) > >> (elp-instrument-function #'org-link-beautify) > >> ;; run agenda > >> ;; M-x elp-results > >> > >> Another suggestion would be invoking debug-on-entry for you function, > >> for org-activate-links, and for org-agenda-finalize. > >> > >> Best, > >> Ihor > >> > >> > >> > >> > >> "numbch...@gmail.com" writes: > >> > >> > I tried use debug-on-entry on: > >> > + org-agenda-list(nil) > >> > - org-agenda-mode() > >> > + org-agenda-set-mode-name() > >> > - org-update-dblock > >> > + org-dblock-write:clocktable > >> > > >> > But got no lucky, Then I followed your another suggestion, use > profiler: > >> > > >> > I got a very big message log, (not suitable for paste in email, so I > >> paste > >> > it on Gist) > >> > > >> > - CPU profiler report: https://www.pastery.net/gststf/ > >> > - Memory profiler report: > https://www.pastery.net/gststf+qzyxaf/#qzyxaf > >> > > >> > The very deepest call stacks seems the output format is not long > enough, > >> so > >> > can't display. > >> > > >> > Your suggestion is very useful, I can see what function is invoked > many > >> > times. But still can't understand what's the cause. > >> > > >> > [stardiviner] GPG key ID: 47C32433 > >> > IRC(freeenode): stardiviner Twitter: @numbchild > >> > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 > >> > Blog: http://stardiviner.github.io/ > >> > > >> > > >> > On Sat, Aug 15, 2020 at 2:02 PM Ihor Radchenko > >>
Re: [PATCH] improve ol-man.el with occur searching
Thanks for reviewing my code and points. :) Fixed in this attached patch. [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Sun, Aug 16, 2020 at 5:54 PM Nicolas Goaziou wrote: > Hello, > > "numbch...@gmail.com" writes: > > > With this patch, ol-man.el link type can be a link like this: > > ```org > > [[man:grep::--extended-regexp][grep --extended-regexp]] > > ``` > > Occur will auto search "--extended-regexp" string in man page buffer. > > Thanks. > > > +PATH should be a topic that can be thrown at the man command. > > +If PATH contains extra ::STRING which will use `occur' to search > > +matched strings in man buffer." > > > + (string-match "\\(.*?\\)\\(?:::\\(.*\\)\\)?$" path) > > + (let* ((command (match-string 1 path)) > > + (search (match-string 2 path))) > > +(funcall org-man-command command) > > +(with-current-buffer (concat "*Man " command "*") > > This should only be called if search is non-empty. > > > + (occur search > > Why occur? Org uses `search-forward' for [[foo.org::text]] text links, > and uses `occur' with [[foo.org::/text/]] links. > > Wouldn't it be more idiomatic to use a regular text search here? > > Regards, > -- > Nicolas Goaziou > From 73b9e6d8e229f46b9d95f666f0bfb1c2a7e3c0af Mon Sep 17 00:00:00 2001 From: stardiviner Date: Fri, 14 Aug 2020 12:37:42 +0800 Subject: [PATCH] ol-man.el: Add searching support in man page buffer * contrib/lisp/ol-man.el (org-man-open): Support auto searching man page buffer with search-forward. --- contrib/lisp/ol-man.el | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/contrib/lisp/ol-man.el b/contrib/lisp/ol-man.el index 5cb7e0155..b21ed9eba 100644 --- a/contrib/lisp/ol-man.el +++ b/contrib/lisp/ol-man.el @@ -37,8 +37,17 @@ (defcustom org-man-command 'man (defun org-man-open (path _) "Visit the manpage on PATH. -PATH should be a topic that can be thrown at the man command." - (funcall org-man-command path)) +PATH should be a topic that can be thrown at the man command. +If PATH contains extra ::STRING which will use `occur' to search +matched strings in man buffer." + (string-match "\\(.*?\\)\\(?:::\\(.*\\)\\)?$" path) + (let* ((command (match-string 1 path)) + (search (match-string 2 path))) +(funcall org-man-command command) +(when search + (with-current-buffer (concat "*Man " command "*") + (goto-char (point-min)) + (search-forward search) (defun org-man-store-link () "Store a link to a README file." -- 2.27.0
Re: [PATCH] Update org-clock-out-time when resolving clocks
Benson Chu writes: > I noticed this while using `org-resolve-clocks' when > `org-clock-continuously' was set to true. > > Let's say I clock into "Task 1" at 12:00, and then at 12:30, I start > working on "Task 2". Then, at 12:45, I notice that I forgot to clock out > of "Task 1". No worries, org-mode has `org-resolve-clocks'! So, I invoke > `org-resolve-clocks', keep 30 minutes, and then clock into "Task > 2". However, when I clock in, the clock start time is 12:45, violating > the promise that `org-clock-continuously' makes. > > This patch updates the variable `org-clock-out-time' when `org-clock-out' > gets passed an `at-time', which fixes the issue I run into. Thanks for the patch. It looks correct to me. > The patch is attached. Is there anything else I need to do? The only thing I noticed missing is a TINYCHANGE cookie... > Subject: [PATCH] org-clock.el: Update org-clock-out-time from > org-resolve-clocks > > * lisp/org-clock.el (org-clock-out): If `at-time' was passed, set > org-clock-out-time to that value. Otherwise, set it to now. ... here. I've added it when applying (bd97851c4). Thanks again.
Re: [BUG] The latest commit "f4687993c53a5339e" caused inline image preview try to convert PDF file link
Hello, "numbch...@gmail.com" writes: > The latest commit "f4687993c53a5339e" added "pdf" file type into inline > image rules. No, it doesn't. "pdf" was already in the list before this commit. > This caused org-toggle-inline-image try to convert large PDF > into png images. Caused very long time suspend. You can customize the variable and remove "pdf". Regards, -- Nicolas Goaziou
