[TYPO REPORT] A typo in the Org Manual
Greetings, There seems to be a typo in the Org Manual. In section 13.8.4: Beamer specific syntax, in the segment showed below, The `#+END_BEAMER' part does neither run correctly nor makes sense, The correct code here should be `#+END_EXPORT'. > Insert Beamer-specific code using the following constructs: >> #+BEAMER: \pause >> #+BEGIN_EXPORT beamer >> Only Beamer export back-end exports this. >> #+END_BEAMER >> Text @@beamer:some code@@ within a paragraph. This typo is present on the HTML version of the manual that you could find on the website: https://orgmode.org/org.html#Beamer-specific-syntax I'm actually new to mailing-list related development procedure so I'm still learning, but it might be possible for someone who's proficient in this procedure to quickly fix this little typo. Good day for all. -- ika
Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
> > About the cpu+mem profiler-report. cpu+mem report should generate two reports: one for cpu time and one for memory. I meant you to save both (there are two buffers). Sorry for not being clear. Best, Ihor
Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
Hi. Ihor. > "Ihor" == Ihor Radchenko writes: [...] Ihor> Makes sense. If you want to squeeze maximum out of Emacs startup and do not update Ihor> frequently, you may look into Ihor> https://archive.casouri.cat/note/2020/painless-transition-to-portable-dumper/index.html Yes. That could be an alternative. on the emacs-28 I can not get 2 weeks of uptime because of this error. bug#57504 On the past on emacs-27 I got almost two months of uptime. About the cpu+mem profiler-report. [profiler-profile "28.1" memory #s(hash-table size 487 test equal rehash-size 1.5 rehash-threshold 0.8125 data ([timer-relative-time run-at-time execute-extended-command funcall-interactively call-interactively command-execute nil nil nil nil nil nil nil nil nil nil] 88 [timer--time-setter timer-set-time run-at-time execute-extended-command funcall-interactively call-interactively command-execute nil nil nil nil nil nil nil nil nil] 40 [timer--time-less-p timer--activate timer-activate run-at-time execute-extended-command funcall-interactively call-interactively command-execute nil nil nil nil nil nil nil nil] 128 [timer--time-setter timer-set-idle-time run-with-idle-timer eldoc-schedule-timer nil nil nil nil nil nil nil nil nil nil nil nil] 40 [timer--time-less-p timer--activate timer-activate-when-idle run-with-idle-timer eldoc-schedule-timer nil nil nil nil nil nil nil nil nil nil nil] 72 [nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil] 23892 [timer--time-less-p timer--activate timer-activate-when-idle timer-event-handler nil nil nil nil nil nil nil nil nil nil nil nil] 108 [execute-extended-command--shorter-1 execute-extended-command--shorter-1 execute-extended-command--shorter "#" apply timer-event-handler nil nil nil nil nil nil nil nil nil nil] 576 [completion-pcm--string->pattern completion-pcm--find-all-completions completion-pcm-try-completion "#" completion--some completion--nth-completion completion-try-completion execute-extended-command--shorter "#" apply timer-event-handler nil nil nil nil nil] 512 [completion-pcm--pattern->regex completion-pcm--all-completions completion-pcm--find-all-completions completion-pcm-try-completion "#" completion--some completion--nth-completion completion-try-completion execute-extended-command--shorter "#" apply timer-event-handler nil nil nil nil] 576 [completion-pcm--all-completions completion-pcm--find-all-completions completion-pcm-try-completion "#" completion--some completion--nth-completion completion-try-completion execute-extended-command--shorter "#" apply timer-event-handler nil nil nil nil nil] 1088 [completion-pcm--merge-completions completion-pcm--merge-try completion-pcm-try-completion "#" completion--some completion--nth-completion completion-try-completion execute-extended-command--shorter "#" apply timer-event-handler nil nil nil nil nil] 512 [completion-pcm--merge-try completion-pcm-try-completion "#" completion--some completion--nth-completion completion-try-completion execute-extended-command--shorter "#" apply timer-event-handler nil nil nil nil nil nil] 8188 [completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil nil nil nil nil nil nil nil] 20974 [timer-relative-time run-at-time undo-auto--boundary-ensure-timer undo-auto--undoable-change read-from-minibuffer completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil nil nil] 64 [timer--time-setter timer-set-time run-at-time undo-auto--boundary-ensure-timer undo-auto--undoable-change read-from-minibuffer completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil nil] 40 [timer--time-less-p timer--activate timer-activate run-at-time undo-auto--boundary-ensure-timer undo-auto--undoable-change read-from-minibuffer completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil] 48 [viper-minibuffer-post-command-hook read-from-minibuffer completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil nil nil nil nil nil] 760 [read-from-minibuffer completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil nil nil nil nil nil nil] 24594 [timer--time-less-p timer--activate timer-activate-when-idle timer-event-handler read-from-minibuffer completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil nil nil] 1296 [call-interactively command-execute read-from-minibuffer completing-read-default completing-read read-extended-command byte-code call-interactively command-execute nil nil nil nil nil nil nil] 152 ["#" "#" apply "#" apply self-insert-command funcall-interactively call-interactively command-execute
Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
> > Ihor> Can you: 1. Load your agenda 2. Start 'cpu+mem profiler 3. > Rebuild the agenda 4. Share the > Ihor> obtained 'cpu _and_ 'mem reports > > I found an issue. > --8<---cut here---start->8--- > void-function org-looking-at > --8<---cut here---end--->8--- > Oops. Fixed. > Ihor> native-comp is improving things proportionally. It should > actually have higher impact on > Ihor> lower-end machine. I recommend native-comp unless you update > frequently (and hence need to > Ihor> re-compile using native-comp often). > > On my case. My distro which is archlinux-arm aka alarm for 32bits does > not provide the compiled package libgccjit. So compiling it takes > several hours on this little machine. cross-compiling it takes almost > 1h, but preparing the machine for cross-compilation takes time also. So > my conclusion is 'it does not worth the hassle'. > Makes sense. If you want to squeeze maximum out of Emacs startup and do not update frequently, you may look into https://archive.casouri.cat/note/2020/painless-transition-to-portable-dumper/index.html Best, Ihor
Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
Hi. Ihor > "Ihor" == Ihor Radchenko writes: [...] Ihor> Can you: 1. Load your agenda 2. Start 'cpu+mem profiler 3. Rebuild the agenda 4. Share the Ihor> obtained 'cpu _and_ 'mem reports I found an issue. --8<---cut here---start->8--- void-function org-looking-at --8<---cut here---end--->8--- Ihor> BTW, is your Emacs 28 using native-comp? >> >> NO. But on this lower-end machine there is no too much difference. Ihor> native-comp is improving things proportionally. It should actually have higher impact on Ihor> lower-end machine. I recommend native-comp unless you update frequently (and hence need to Ihor> re-compile using native-comp often). On my case. My distro which is archlinux-arm aka alarm for 32bits does not provide the compiled package libgccjit. So compiling it takes several hours on this little machine. cross-compiling it takes almost 1h, but preparing the machine for cross-compilation takes time also. So my conclusion is 'it does not worth the hassle'. Best Regards
Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]
andrés ramírez writes: > Ihor> I also pushed a couple of new small optimizations, according to > your profiler report. Can > Ihor> you try again with the latest main? > > Done. The time is now 32s. > The produced profiler report. Thanks! I pushed some more optimizations, though I expect the improvement to be no more than a few %. I can still try to improve things a little, but then I need a more zoomed-in report for agenda rebuild time without combining it with loading elisp libraries. Can you: 1. Load your agenda 2. Start 'cpu+mem profiler 3. Rebuild the agenda 4. Share the obtained 'cpu _and_ 'mem reports > Ihor> BTW, is your Emacs 28 using native-comp? > > NO. But on this lower-end machine there is no too much difference. native-comp is improving things proportionally. It should actually have higher impact on lower-end machine. I recommend native-comp unless you update frequently (and hence need to re-compile using native-comp often). -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: per-file (or, really, per buffer) allowing/disallowing code block execution
Greg Minshall writes: > i'm a bit unclear. does your (single?) Org notebook consist of *one* > file (and thus, [normally? always? my ignorance precedes me], one > buffer), or two files (thus, two buffers). One file, two kinds of "src" blocks. > in the former case (one buffer), i don't know if these proposals will > help. though, maybe as they are flushed out (precedence of the > buffer-local and/or global-local with header line constructs), it > would? Interesting. Suppose I have 'org-confirm-babel-evaluate' set to 'nil' and I answer "no to all" during 'org-babel-execute-buffer'. I would expect that to mean "answer 'no' to every :eval query" block and execute the rest as usual. If so, that would save me from having to answer "no" dozen times. Good point! Rudy -- "I love deadlines. I love the whooshing noise they make as they go by." -- Douglas Adams, The Salmon of Doubt, 2002 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: [PATCH] Re: No mathematics in Texinfo exports
Ihor Radchenko writes: > Applied onto main with minor amendments. Amazing! Thank you so much for guiding me through. Rudy -- "It is no paradox to say that in our most theoretical moods we may be nearest to our most practical applications." -- Alfred North Whitehead, 1861-1947 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]
Ihor Radchenko writes: > Bastien writes: > >>> Also, having an actual mirror in sr.ht means that we may set up automatic >>> tests. WDYT about this idea? >> >> Tests are useful if they prevent contributors from changing the code >> in a way that break them: this must happen before pushing changes to >> the bugfix or main branches. >> >> Automated tests are useful only if we fail to enforce this policy... >> so I'm not in favor of them. > > I agree that running tests is a good idea before pushing changes. > However, it is a big ask for contributors when we need to ensure > compatibility with multiple Emacs versions. Running tests on all the > supported Emacs version simply takes too much time. Not to mention that > installing multiple Emacs versions may not be trivial. Automated tests > could cater backwards compatibility checks. +1 on this. However, I do wonder if different positions are due to different understanding of what we mean when talking about automated tests.
Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
On Wednesday, 21 Sep 2022 at 16:55, Daniel Fleischer wrote:
> I don't understand the usecase, that's why I wasn't really following. If
> you write \vspace{10cm} before some headline, it's going to do the right
> thing even if it "belongs" to a previous headline.
For me, the issue is that I often have many sections that are commented
out or not selected for export. I may also move sections around. In
these cases, the "pre" text ends up in the wrong place or not in effect
at all.
--
: Eric S Fraga, with org release_9.5.4-768-g5bb699 in Emacs 29.0.50
Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
Daniel Fleischer writes:
> I don't understand the usecase, that's why I wasn't really following. If
> you write \vspace{10cm} before some headline, it's going to do the right
> thing even if it "belongs" to a previous headline.
Imagine, for example, that you have defined a LaTeX command that changes
the style of the section (or chapter, subsection, or whatever) below.
And you want to apply it before a certain section. If for any reason you
comment out the preceding section, or mark it as non-exportable, or even
delete it, the preceding command is no longer there when you export to
LaTeX. That would also happen if you move the section.
Best regards,
Juan Manuel
--
--
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
Re: [BUG] can't quit emacs [9.5.4 (release_9.5.4-583-g620fb2 @ /home/user/.emacs.d/el-get/org-mode/lisp/)]
On 21/09/2022 17:25, Aleksas Tunikas wrote: can't quit emacs because of this error, guess i've mess something up, pls help Ensure that you saved all buffers and evaluate (scratch buffer of M-:) (setq kill-emacs-hook nil) I usually fail into such state after compiling Org for Emacs-27 and launching Emacs-26. Once I faced a similar issue playing with remote editing using tramp, but I have not tried to reproduce it. You may provide more information, e.g. copy error from the *Messages* buffer (C-h e) or by enable debug on error. I believe that exit hooks should be more fool proof.
Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
Ihor Radchenko [2022-09-21 Wed 16:55] wrote:
> More concretely, I mean something like
>
> * Section
> :PROPERTIES:
> :attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
> :attr_latex+: :prepend "section"
> \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
> :attr_latex+: :append "section" \setcounter{secnumdepth}{2}
> :attr_latex+: :append "section"
> \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
> :END:
>
> I suggest to use more canonical attr_latex that explicitly limits the
> export backend.
I don't understand the usecase, that's why I wasn't really following. If
you write \vspace{10cm} before some headline, it's going to do the right
thing even if it "belongs" to a previous headline.
If org-latex-classes is not a good enough solution I also think it should
be a general export feature, not specific to latex. In that case you
need a general syntax, e.g. properties like "export_prefix",
"export_postfix" and the code should be as simple as possible, i.e.
copying the text one line before/after the headline.
--
Daniel Fleischer
Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
On 21/09/2022 15:55, Ihor Radchenko wrote:
There is nothing wrong about this, but I feel that this kind of approach
is encouraging to shoot your own leg a bit too much.
I am afraid, it is unavoidable facet of flexibility. Anyway arbitrary
LaTeX command may be inserted using export snippet or block.
Also, :presec/:postsec property names are
confusing --- it is unclear if they are specific to LaTeX. (when about,
say, Beamer)
An example of use case for beamer:
M. ‘quintus’ Gülker. Beamer export: Executing LaTeX between two frames.
Tue, 21 Jun 2022 10:01:03 +0200.
https//list.orgmode.org/87mte6tphc@guelker.eu
* Section
:PROPERTIES:
:attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
:attr_latex+: :prepend "section"
\addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
:attr_latex+: :append "section" \setcounter{secnumdepth}{2}
:attr_latex+: :append "section"
\addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
:END:
I suggest to use more canonical attr_latex that explicitly limits the
export backend.
The only objection is that for ox-html users may expect any attr_html
key-value pairs directly become attributes of the HTML element rather
than control of output at higher level.
Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
Ihor Radchenko writes:
> It may produce unexpected results if "Section" heading is demoted all
> the way to paragraph.
If Section heading is demoted all the way to paragraph, I assume that
the expected will happen: that in the output to LaTeX a string will be
added before \paragraph and another string after the content of
\paragraph, which is perfectly consistent with the behavior of these two
properties. It is not that I intend to insist on a discussion; I just
don't quite understand what you mean. Note that these properties are for
LaTeX fine-tuning, and the user is expected to know what he/she wants
and where he/she wants it. If a user wants the arbitrary LaTeX code
before a certain header to be exported as a section (because, for
example, he/she has defined a command in LaTeX that changes the style of
the next \section), you would expect to put those properties in a
"\section" heading.
> Also, :presec/:postsec property names are
> confusing --- it is unclear if they are specific to LaTeX. (when about,
> say, Beamer)
Yes, I agree with that, and I had already commented on it in my previous
message, based on what Maxim had pointed out before, that the names I
had chosen were too imprecise. I like part of what you propose below:
`:attr_latex: :prepend'.
>>> However, I do agree that per-heading control over latex export is
>>> currently cumbersome.
>>>
>>> The canonical ox-latex approach to customize headline export is
>>> org-latex-classes variable. This variable defines (among other things)
>>> pre/post commands during headline export:
>>
>> Apologies in advance if I misunderstood what you're suggesting, but
>> isn't the "org-latex-classes" property supposed to affect the structure
>> of the entire document? What I'm proposing here is rather something
>> specific to particular headings (and its entire content), like the
>> ":ALT_TITLE:" property. If I understand correctly, what you are
>> suggesting is that org-latex-classes can have "local values" for
>> specific headings, if such headings are 'marked' with some property?
>
> Yes, org-latex-classes is controlling the entire document. What I am
> proposing (as an alternative) is subtree-level equivalent of
> org-latex-classes that is also close to org-latex-classes semantics.
>
> More concretely, I mean something like
>
> * Section
> :PROPERTIES:
> :attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
> :attr_latex+: :prepend "section"
> \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
> :attr_latex+: :append "section" \setcounter{secnumdepth}{2}
> :attr_latex+: :append "section"
> \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
> :END:
>
> I suggest to use more canonical attr_latex that explicitly limits the
> export backend.
I see. But in any case, something like `:prepend "section"' would be
unnecessary (and even counterproductive) for what I'm proposing, but I'm
afraid I didn't explain myself well in the first message. One of the
benefits of approaching this issue with a few minor modifications to
org-latex-headline is that the result is regardless of the section level
at which the property is applied. We may want to prefix the section with
a specific LaTeX code only for \section (or \paragraph or whatever) and
we may want to introduce a more general LaTeX code, level-agnostic.
Explicitly put "section", "subsection", etc, IMHO unnecessarily
complicates things. But I also insist (as I said at the beginning) that
I don't know if this use case can also be extended to other users.
Best regards,
Juan Manuel
--
--
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
[O] Plantuml w/ noweb and cached results
Hello,
I'm not sure if this is a bug in ob-restclient, ob-plantuml, or Babel. If
someone can help me figure out where, I can move this report to GitHub (if
ob-restclient) - otherwise I think it remains here.
I cannot use ob-plantuml if results are cached. See example:
#+NAME: cache-no
#+BEGIN_SRC restclient :jq .[0].address :cache no
GET https://jsonplaceholder.typicode.com/users
#+END_SRC
#+RESULTS: cache-no
#+BEGIN_SRC js
{
"street": "Kulas Light",
"suite": "Apt. 556",
"city": "Gwenborough",
"zipcode": "92998-3874",
"geo": {
"lat": "-37.3159",
"lng": "81.1496"
}
}
#+END_SRC
#+BEGIN_SRC plantuml :noweb yes :file cache-no.png
@startjson
<>
@endjson
#+END_SRC
#+RESULTS:
[[file:cache-no.png]]
The above graphic is generated by plantuml.
#+NAME: cache-yes
#+BEGIN_SRC restclient :jq .[0].address :cache yes
GET https://jsonplaceholder.typicode.com/users
#+END_SRC
#+RESULTS[(2022-09-20 15:52:59) c41e0371fd392d6fbfd07ff4078abf8c387885ea]:
cache-yes
#+BEGIN_SRC js
{
"street": "Kulas Light",
"suite": "Apt. 556",
"city": "Gwenborough",
"zipcode": "92998-3874",
"geo": {
"lat": "-37.3159",
"lng": "81.1496"
}
}
#+END_SRC
#+BEGIN_SRC plantuml :noweb yes :file cache-yes.png
@startjson
<>
@endjson
#+END_SRC
#+RESULTS:
[[file:cache-yes.png]]
The above graphic is an error message. It states,
"Your data does not sound like JSON data".
-k.
n
[BUG] can't quit emacs [9.5.4 (release_9.5.4-583-g620fb2 @ /home/user/.emacs.d/el-get/org-mode/lisp/)]
can't quit emacs because of this error, guess i've mess something up,
pls help
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Emacs : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32,
cairo version 1.16.0)
of 2022-09-21
Package: Org mode version 9.5.4 (release_9.5.4-583-g620fb2 @
/home/user/.emacs.d/el-get/org-mode/lisp/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-fontify-done-headline nil
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-export-before-parsing-hook '(org-attach-expand-links)
org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-roam-find-file-hook '(org-roam-buffer--setup-redisplay-h
org-roam--register-completion-functions-h
org-roam--replace-roam-links-on-save-h
org-roam-db-autosync--setup-update-on-save-h)
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-cycle-optimize-window-after-visibility-change)
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-link-from-user-regexp "|\\<2062\\>"
org-mode-hook '(#[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-fold-show-all append local] 5]
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-roam-ref-annotation-function 'org-roam-ref-read--annotation
org-roam-db-node-include-function #[0 "\300\207" [t] 1]
org-confirm-shell-link-function 'yes-or-no-p
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-protocol-protocol-alist '(("org-roam-node" :protocol "roam-node" :function
org-roam-protocol-open-node)
("org-roam-ref" :protocol "roam-ref" :function
org-roam-protocol-open-ref))
org-roam-capture-preface-hook '(org-roam-capture--try-capture-to-ref-h)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-capture-prepare-finalize-hook '(org-roam-capture--install-finalize-h)
org-roam-preview-function 'org-roam-preview-default-function
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-roam-db-autosync-mode t
org-confirm-elisp-link-function 'yes-or-no-p
org-log-buffer-setup-hook '(org-roam-log--setup)
org-roam-capture-new-node-hook '(org-roam-capture--insert-captured-ref-h)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-fold-core-isearch-open-function 'org-fold-core--isearch-reveal
org-persist-before-write-hook '(org-element--cache-persist-before-write)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-link-shell-confirm-function 'yes-or-no-p
org-babel-pre-tangle-hook '(save-buffer)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-roam-log-setup-hook '(org-roam--register-completion-functions-h)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-roam-node-annotation-function 'org-roam-node-read--annotation
org-link-parameters '(("eww" :follow org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("doi" :follow
org-link-doi-open :export org-link-doi-export)
("roam" :follow org-roam-link-follow-link)
("attachment" :follow org-attach-follow :complete
org-attach-complete-link) ("id" :follow org-roam-id-open)
("mu4e" :follow mu4e-org-open :store
Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)
On Wed, Sep 21, 2022 at 10:59:14AM +0200, Russell Adams wrote: > On Wed, Sep 21, 2022 at 04:05:56PM +0800, Ihor Radchenko wrote: > > Russell Adams writes: > > > > >> I am wondering if we could create a common Org dev matrix room for quick > > >> discussions and then copy the transcript to the relevant ML thread, when > > >> necessary. > > > > > > We have an IRC channel for real time chat. Join in anytime. > > > > The disadvantage of IRC is absence of message history. > > Without history, small-sized channels like I am proposing (dedicated to > > Org mode devs) are not very useful. We live in different time zones and > > countries. > > I disagree. That's why most IRC users stay logged in. > > IRC is most accessible, and if you insist there is a Matrix bridge to > Libera. Let me pose this differently. The #org-mode channel has a large footprint already, though lower utilization than #emacs. There are 230 org users online right now. It would be great to see some dev discussions on IRC, and if we ever get too much traffic, maybe make a #org-mode-dev channel. I'd encourage you to try to use the existing resources first, especially where the user base is. Then split things up later. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
Hi Eric, > And I would hope to have “:beamer:” (or “:attr_beamer:”) as well! I’d hope that pre/post-ending attributes would be backend-generalised. All the best, Timothy
Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
On Wednesday, 21 Sep 2022 at 16:55, Ihor Radchenko wrote:
> More concretely, I mean something like
>
> * Section
> :PROPERTIES:
> :attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
> :attr_latex+: :prepend "section"
> \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
> :attr_latex+: :append "section" \setcounter{secnumdepth}{2}
> :attr_latex+: :append "section"
> \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
> :END:
This looks fine to me. I don't particularly care about the actual
syntax. However, a minor point out of curiosity: why not just ":latex:"
for the property name?
And I would hope to have ":beamer:" (or ":attr_beamer:") as well!
Thank you,
eric
--
: Eric S Fraga, with org release_9.5.4-768-g5bb699 in Emacs 29.0.50
Re: svg file from tikz picture
reza writes: First of all, thanks a lot for digging into ob-latex! This file has not been touched seriously since 7 years ago and the last major change is 8 years ago (510e70379). > When having a look at the code inside ob-latex.el I also encountered a > few stuff which made me wondering: > > 1. png generation is done with the preview code inside org.el > (org-create-formula-image), there is also a perfectly fine svg preview > function but this does not get used for the svg extension which does the > svg conversion without any external tools like inkscape (see > https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L156 and > https://github.com/bzg/org-mode/blob/main/lisp/org.el#L3181) This, and many other oddities are likely related to the fact that org.el preview code is more up-to-date, while ob-latex have not been changed, including its assumptions about org.el's LaTeX preview. I suspect that some features in org.el were implemented separately, but did not get integrated with ob-latex. > 2. there is a tikz extension switch which does insert the code verbatim, > which in my opinion does create a whole bunch of problems (backend > dependency issues). Not to mention that it also mimics behaviour which > is reserved for the header :results (see > https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L177). Could you please elaborate? > 3. there is a html extension switch with an unclear purpose to me (in > what scenario would you want to produce an html file?). It also has some > strange (and contradicting) checking if an svg or an html file got > produced. As far as I can tell this code never gets executed and is > therefore pointless (see > https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L181). Well. We do not remove existing features unless there is strong justifications. See https://bzg.fr/en/the-software-maintainers-pledge/ As for the contradicting checking, it is likely a classic copy-paste error when html and svg branches of the code got split. > 4. the whole pdf generation looks like duplicate code which is already > done in other parts of the code base (ox-latex.el and for the svg > extension) it ais also not using the variable org-babel-latex-begin-env > and org-babel-latex-end-env (see > https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L225). Again, I am not sure here. It is a very old code. My best guess is that it was developer prior to ox-latex. The best hint I can provide is https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html that should document some details of the logic. > I don't want to criticize anyone, I just want to find answers for in my > opinion some strange decisions. Criticism is welcome as long as it is aiming to improve Org. No worries. If you want to dig further, I can also suggest to use git blame and dig into mailing list messages from Eric Schulte, the original author of ob-latex. > My propositions for refactoring is: > > 1. use the svg preview code for svg generation (and therefore ditching > the whole imagemagick headers) Note that imagemagick argument does more than you may expect. For example, one can apply various image effects on the generated file via imagemagick: https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html >> :imagemagick >> When not nil the source block is processed to pdf and the pdf is converted >> with ImageMagick to whatever is given as :file. Thus, the format is not >> limited to png. >> :iminoptions >> This is passed to ImageMagick before the pdf file. >> :imoutoptions >> This is passed to ImageMagick before the output file. That said, I do agree that re-using svg preview generation sounds like an improvement. But we need to be careful not to remove the existing functionality. > 2. remove the whole tikz generation completely > > 3. remove the whole html generation completely I did not see justification why we need to do it other than lack of ideas why they are useful. For now, I do not think that removing tikz/html generation is a good idea. According to https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html, tikz generation can be useful during LaTeX export. > 4. try to merge pdf generation with org.el and ox-latex.el or > incorporating it into he preview code and > org-preview-latex-process-alist (this is probably a whole project of it own) This sounds like a very good idea. I'd merge the preview code from org.el into ob-latex. > WDYT? Improving ob-latex is most welcome. I think that the first step is incremental refactor. Let's not remove features until we have less tangled code that is easier to understand. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] org-contrib/babel/languages/ob-doc-plantuml.org: ASCII output
Actually, I just looked at the org-mode documentation on the site today, and noticed that the examples of use section (https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-plantuml.html#org6cd541e) has the wrong ASCII output. The output should be ,---. ,-. |Bob| |Alice| `-+-' `--+--' | Hello World! | |-->| ,-+-. ,--+--. |Bob| |Alice| `---' `-' but instead it's just Bob -> Alice : Hello World! The results appear just find when I execute the org src code block on my local machine. Joseph
Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)
On Wed, Sep 21, 2022 at 04:05:56PM +0800, Ihor Radchenko wrote: > Russell Adams writes: > > >> I am wondering if we could create a common Org dev matrix room for quick > >> discussions and then copy the transcript to the relevant ML thread, when > >> necessary. > > > > We have an IRC channel for real time chat. Join in anytime. > > The disadvantage of IRC is absence of message history. > Without history, small-sized channels like I am proposing (dedicated to > Org mode devs) are not very useful. We live in different time zones and > countries. I disagree. That's why most IRC users stay logged in. IRC is most accessible, and if you insist there is a Matrix bridge to Libera. -- Russell Adamsrlad...@adamsinfoserv.com https://www.adamsinfoserv.com/
Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section
Adding Daniel Fleischer (the ox-latex maintainer) to this exchange.
Juan Manuel Macías writes:
> Ihor Radchenko writes:
>
>> I do not like this idea.
>> Please remember that headlines may be exported as parts, sections,
>> subsections, list items, or paragraphs depending on the headline level.
>> Arbitrary pre/post commands may unexpectedly break things during export.
>
> I don't see why, if the user knows LaTeX and knows what he/she is doing.
> Sometimes it's just adding an "\addtocontents" just before the
> section/subsection,etc. The property that adds the string before and the
> property that adds the string after are understood to affect the entire
> heading at the current level and its contents, including lower levels.
> For example, if someone wants the current heading (and all its
> sublevels) not to be included in the TOC but to be included in the
> headers of the pages, it would suffice to (I keep here the original name
> of the properties that I proposed in the patch, but I think Maxim's
> proposed name is more accurate):
>
> ---
>
> * Section
> :PROPERTIES:
> :presec: \setcounter{secnumdepth}{0}
> :presec+:
> \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
> :postsec: \setcounter{secnumdepth}{2}
> :postsec+:
> \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
> :END:
> Lorem ipsum dolor.
There is nothing wrong about this, but I feel that this kind of approach
is encouraging to shoot your own leg a bit too much. It will be better
if Org provides a semantics that is facilitating more safe approach.
More below.
> Which would pass to LaTeX as:
>
> \setcounter{secnumdepth}{0}
> \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
>
> \section{Section}
> Lorem ipsum dolor.
> \subsection{Subsection one}
> lorem
> \subsection{Subsection two}
> ipsum
>
> \setcounter{secnumdepth}{2}
> \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
> --
>
> (The above can even be simplified from LaTeX by defining a simple
> environment, but I've exemplified it like this to make it look better).
>
> In what situations might this return unexpected results?
It may produce unexpected results if "Section" heading is demoted all
the way to paragraph. Also, :presec/:postsec property names are
confusing --- it is unclear if they are specific to LaTeX. (when about,
say, Beamer)
>> However, I do agree that per-heading control over latex export is
>> currently cumbersome.
>>
>> The canonical ox-latex approach to customize headline export is
>> org-latex-classes variable. This variable defines (among other things)
>> pre/post commands during headline export:
>
> Apologies in advance if I misunderstood what you're suggesting, but
> isn't the "org-latex-classes" property supposed to affect the structure
> of the entire document? What I'm proposing here is rather something
> specific to particular headings (and its entire content), like the
> ":ALT_TITLE:" property. If I understand correctly, what you are
> suggesting is that org-latex-classes can have "local values" for
> specific headings, if such headings are 'marked' with some property?
Yes, org-latex-classes is controlling the entire document. What I am
proposing (as an alternative) is subtree-level equivalent of
org-latex-classes that is also close to org-latex-classes semantics.
More concretely, I mean something like
* Section
:PROPERTIES:
:attr_latex: :prepend "section" \setcounter{secnumdepth}{0}
:attr_latex+: :prepend "section"
\addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
:attr_latex+: :append "section" \setcounter{secnumdepth}{2}
:attr_latex+: :append "section"
\addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
:END:
I suggest to use more canonical attr_latex that explicitly limits the
export backend.
Further, it mentions a regexp limiting the applicable LaTeX environment
("section"). In other environments, the code will be omitted.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
Re: strange errors with org-element-cache-reset and jit-lock-function void-variable org-element-citation-prefix-re
Daniel Ortmann writes: > These two lines are in my *Messages* buffer: > File mode specification error: (void-function org-element-cache-reset) > Error during redisplay: (jit-lock-function 1) signaled (void-variable > org-element-citation-prefix-re) Confirmed. I know how to "fix" this (can just add require 'org-element into `org-mode'), but I do not fully understand what is going on on Emacs side. Let's see what Emacs devs say. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57972 -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Org mode links: Open a PDF file at a given page and highlight a given string
Max Nikulin writes: >> I think that it is a very good idea for Org core to support search terms >> in file links that are handled by Free Software. > > Maybe I misunderstand something, but your stress on Free Software here > surprised me. I did not mention explicitly any proprietary application > such as Adobe Reader. On the other hand support of Chromium (that is > free) unavoidably assumes Google Chrome and likely MS Edge with other > derived products with same customization as chromium vs. > chromium-browser command name discrepancy in Linux distros. I was referring to GPL-compatible software. If we have better integration with Libre/Free Software, it is suitable for Org core. IMHO. >> Moreover, I think that we should, by default, auto-detect and use Free >> Software to open file links, when such software is installed on user >> machine (unless the user explicitly instruct otherwise). > > Could you, please, elaborate? E.g. for PDF file default is docview mode. > Unless a user has an override in `org-file-apps', likely it should be > used. Perhaps system-wide handler may be considered as a candidate, but > on linux it means XDG MIME handlers that is not supported by Emacs, so > only mailcap remains. Both XDG database and mailcap have no notion of > location within the file to open. I am referring to cdr of the org-file-apps entries. docview will correspond to `emacs' command. XDG will correspond to `system'. And we have `default', which could detect Libre Software, if installed. >> I see Free Software support as dedicated files like ol-evince, >> ol-okular, etc. The file functionality and common function may probably >> be factored out into ol-file library. > > I am considering a single package, something like org-pdfviewer, that > has definitions for all popular viewers: evince, okular, firefox, > chromium, etc. I believed that user should explicitly configure > preferred viewer by either adding an entry with supplied function to > `org-file-apps' or this package has its own defcustoms and the entry > injected to some variable as you suggested in > Ihor Radchenko. Re: [PATCH v2] org.el: Fix percent substitutions in > `org-open-file' Mon, 05 Sep 2022 13:46:41 +0800. > https://list.orgmode.org/875yi2xtj2.fsf@localhost > > The point of defcustoms in the package instead of (or in addition to) > `org-file-apps' is that evince and okular support more formats than PDF. I understand your idea. What I am suggesting is to implement support for a subset of popular viewers (the Libre ones) and add it to Org core. Support for non-Libre viewers could be added ad third-party packages based on the Org core implementation. The default viewer may be customized by user according to, say, org-file-apps-default-pdf-viewer defaulting to 'auto (detect). This customization will only take effect when the PDF file entry in org-file-apps sets the command to `default'. Hope I made my idea more clear. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] [BUG] org.el: Fix first call of `org-paste-subtree'
Max Nikulin writes: >> The main problem the old code solves is working around user error when >> kill-ring is empty. We do not really want to err in such cases; just >> handle empty kill ring specially. > > From my point of view "kill ring is empty" user error clearly describes > what happens in such case, so I do not see any point to spit suggestion > to try simple yank instead. >> I agree that (and kill-ring ...) condition misses the system clipboard. >> The proper way to handle this issue is explicitly catching "Kill ring is >> empty" error thrown by `current-kill' (i.e. `condition-case'). > > Why do you believe that just allowing to propagate this error is worse? I agree with you for `org-paste-subtree', but not for `org-kill-is-subtree-p' and `org-capture-fill-template'. The two latter ones also use (and kill-ring ...). >> We have 3 occurrences of (and kill-ring (current-kill 0)) constructs in >> the code and may fix the problem either by replacing each instance with >> `condition-case' or we may create a separate macro/function in org-macs >> and use it. > > Other cases (such as the one at the end of `org-paste-subtree' to > determine if yanked text should be folded) require more care. This particular case, kill-ring test appears to be unnecessary (see snippet below). current-kill should return non-nil because otherwise "The kill is not a (set of) tree(s)" error would be thrown earlier. (when (and (not for-yank) ; in this case, org-yank will decide about folding kill-ring (equal org-subtree-clip (current-kill 0)) org-subtree-clip-folded) ;; The tree was folded before it was killed/copied (org-fold-subtree t)) The other piece (when remove (pop kill-ring)) is indeed trickier and we may need to test (equal org-subtree-clip (current-kill 0)) like the above. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Org mode links: Open a PDF file at a given page and highlight a given string
Max Nikulin writes: >> I think that it is a very good idea for Org core to support search terms >> in file links that are handled by Free Software. > > Maybe I misunderstand something, but your stress on Free Software here > surprised me. I did not mention explicitly any proprietary application > such as Adobe Reader. On the other hand support of Chromium (that is > free) unavoidably assumes Google Chrome and likely MS Edge with other > derived products with same customization as chromium vs. > chromium-browser command name discrepancy in Linux distros. I was referring to GPL-compatible software. If we have better integration with Libre/Free Software, it is suitable for Org core. IMHO. >> Moreover, I think that we should, by default, auto-detect and use Free >> Software to open file links, when such software is installed on user >> machine (unless the user explicitly instruct otherwise). > > Could you, please, elaborate? E.g. for PDF file default is docview mode. > Unless a user has an override in `org-file-apps', likely it should be > used. Perhaps system-wide handler may be considered as a candidate, but > on linux it means XDG MIME handlers that is not supported by Emacs, so > only mailcap remains. Both XDG database and mailcap have no notion of > location within the file to open. I am referring to cdr of the org-file-apps entries. docview will correspond to `emacs' command. XDG will correspond to `system'. And we have `default', which could detect Libre Software, if installed. >> I see Free Software support as dedicated files like ol-evince, >> ol-okular, etc. The file functionality and common function may probably >> be factored out into ol-file library. > > I am considering a single package, something like org-pdfviewer, that > has definitions for all popular viewers: evince, okular, firefox, > chromium, etc. I believed that user should explicitly configure > preferred viewer by either adding an entry with supplied function to > `org-file-apps' or this package has its own defcustoms and the entry > injected to some variable as you suggested in > Ihor Radchenko. Re: [PATCH v2] org.el: Fix percent substitutions in > `org-open-file' Mon, 05 Sep 2022 13:46:41 +0800. > https://list.orgmode.org/875yi2xtj2.fsf@localhost > > The point of defcustoms in the package instead of (or in addition to) > `org-file-apps' is that evince and okular support more formats than PDF. I understand your idea. What I am suggesting is to implement support for a subset of popular viewers (the Libre ones) and add it to Org core. Support for non-Libre viewers could be added ad third-party packages based on the Org core implementation. The default viewer may be customized by user according to, say, org-file-apps-default-pdf-viewer defaulting to 'auto (detect). This customization will only take effect when the PDF file entry in org-file-apps sets the command to `default'. Hope I made my idea more clear. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)
Russell Adams writes: >> I am wondering if we could create a common Org dev matrix room for quick >> discussions and then copy the transcript to the relevant ML thread, when >> necessary. > > We have an IRC channel for real time chat. Join in anytime. The disadvantage of IRC is absence of message history. Without history, small-sized channels like I am proposing (dedicated to Org mode devs) are not very useful. We live in different time zones and countries. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH v6] New: auto display inline images under subtree when `org-cycle'.
"Christopher M. Miles" writes: > I checked out your patch, it's fine to me. Should be fine to apply. Done. Applied onto main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=95df82c5fcf926088da2aaab9354a902956ae881 Going back to cycling inline image visibility now. I think that the first step should be extending `org-remove-inline-images' and `org-display-inline-images' to work on regions. `org-display-inline-images' already provides BEG and END optional arguments, but it currently clears all the images in buffer unconditionally. We will need to make `org-remove-inline-images' work on region and modify `org-display-inline-images' to not affect images outside the provided region. Then, we can modify `org-toggle-inline-images' accordingly and make use of it in org-cycle.el to toggle images in section/subtree. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] Re: No mathematics in Texinfo exports
Rudolf Adamkovič writes: > Please see the attached patch where I attempt to fix every issue you > pointed out. I also split the tests into smaller functions for better > maintainability. Please, let me know what you think about my latest > attempt. Thank you for your guidance! Applied onto main with minor amendments. Thanks for your contribution! https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c940b460c7bb31e98089286a5a45306cc27034cc -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: You can now support Org-mode through https://liberapay.com/org-mode/
"Cook, Malcolm" writes: > Thanks for all you do – donation forthcoming! Thanks! I hope more Org contributors will join the Liberapay team. -- Bastien
