Re: Proposal: 'executable' org-capture-templaes
Arthur Miller writes: > I was playing with org-capture today, and it strike me that it could be used > as > a simple and lightweight alternative to create GUIs for user options, somewhat > resembling the use of well-known hydra/transient or built-in help macro or > easy > menu. Is there any reason why you dislike transient (now part of Emacs core)? We actually had multiple threads discussing possibility to port all the Org dialogues to transient. > I would like to propose a small 'feature/change' to org-capture templates, to > inlude a new target: 'exec'. It should be followed by a function to be > executed. > > I believe that this is a simple change that does not intrude on anything else > in > org-capture, you can see the attached patch. The goal is to just circumwent > the > createion of capture buffer, bookmark and other processing done by org-capture > etc. However there might be things I am not aware of, so if someone have more > insight, it is welcomed to hear. It seems to be quite out of scope of org-capture. If anything, capture menu might be factored out to a generic menu framework. But again, we already have transient achieving the same goal. Best, Ihor
Re: About opening issues vs email [Was: About 'inline special blocks']
Hey Kaushal! Thanks for your insight. On Thu, May 26 2022 17:22, Kaushal Modi wrote: > - Issues section is there for a reason. If the repo owner did not like > people opening Issues, they would disable that section. I agree with Ihor's response for this point. > - Conversations and discussions are better formatted and readable in > the issue threads. I disagree with this one, I find mailing lists much more well-formatted, readable and conversation/discussion friendly than PRs on GitHub (it mostly has to do it the web UI, TBH [1]). > - If the feature is implemented, I like to link that commit or PR to > that issue so that the entire history and reasoning behind a feature > addition (esp. if it's a breaking one) can be followed through > hyperlinks from the commit log to the issue thread. But it isn't this particular case. I only emailed asking if he would have interest on merging his work on Org-mode core, which isn't really a feature or a modification on the codebase. Nonetheless, one of the first things I said was that I could open an issue on the public repo if he'd rather have it documented there as well. I just felt more inclined to send him an e-mail because 1. he made it public, and 2. I feel more comfortable using e-mails for communicating such things. [1] https://asylum.madhouse-project.org/blog/2018/07/24/on-git-github-and-email/ Regards, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: export regions of a org files to other formats (most likely only to a buffer).
Samuel Wales writes: > i would say that respecting narrowing is expected in emacs, as a kind > of pseudo-buffer bob/eob, so it would be surprising to find that it > might not be so in a part of org. lack of it should be mentioned, but > might be a bug. I think the main confusion was about active region, not narrowing. Respecting active region is not as much conventional. Best, Ihor
Re: About opening issues vs email [Was: About 'inline special blocks']
Kaushal Modi writes: >> I reached out to him on e-mail, if he doesn't reply there I'll create >> the issue. Thanks! > > Just saying this based on my personal preference. I would rather > prefer that people directly open an issue on Github than emailing me > personally. > > Reasons: > > - Issues section is there for a reason. If the repo owner did not like > people opening Issues, they would disable that section. I guess it depends. Some people may not prefer public discussions. At least not always. The question here is not exactly an issue to be fixed, but something much more complex. > - Conversations and discussions are better formatted and readable in > the issue threads. How so? No branching of replies (fixed linear layout). No attachments. Often yet another flavor of markdown. > - If the feature is implemented, I like to link that commit or PR to > that issue so that the entire history and reasoning behind a feature > addition (esp. if it's a breaking one) can be followed through > hyperlinks from the commit log to the issue thread. You can equally link a public email exchange. Best, Ihor
Re: [tip] org-publish to work with (very) large books
Juan Manuel Macías writes:
> Sorry for not explaining the \input part in more detail. I think the
> essential part here is that all the .tex files (the subdocuments) are
> already created by org-publish before I compile the master document. The
> master document simply stores all the subdocuments: I use
> \input{subdocument.tex} instead of the org #+INCLUDE directive (not the
> LaTeX \include command). The master document calls ready-made TeX files,
> not Org files. And it is independent of the whole org-publish process,
> which is responsible for creating only the parts of the book.
> This
> procedure, apart from being able to compile parts of the book in real
> time with latexmk -pvc, allows me to have more control over these parts.
> But it makes more sense to use it when dealing with very long books. The
> first time I used it was in a book of more than 1000 pages :-)
I am not sure if I understand correctly. Do you mean that you only
preview the book parts you are currently working on via latexmk -pvc?
What kind of more control are you referring to?
Best,
Ihor
[BUG] Hide leading space when hiding keyword
`org-hidden-keywords' was introduced in Org 9.5 and allows hiding keywords like "#+title:" at the beginning of the buffer. However if you have something like #+title: A nice title " A nice title" is displayed at the beginning. AFAIK it's common to have a space after "#+title: " in Org files (at least I do it in all my files). It'd be nice to have an option to remove display of this space for keywords included in `org-hidden-keywords'. (Correct me if there's a way to do this already.)
Re: export regions of a org files to other formats (most likely only to a buffer).
[i realized there is a footnote to my comment about narrowing. of course there might be questions about what org will do if there are things that refer to outside the region, like links or macro definitions.] On 5/26/22, Samuel Wales wrote: > i would say that respecting narrowing is expected in emacs, as a kind > of pseudo-buffer bob/eob, so it would be surprising to find that it > might not be so in a part of org. lack of it should be mentioned, but > might be a bug. > > > On 5/25/22, Ihor Radchenko wrote: >> Uwe Brauer writes: >> Could you please clarify which part of the function docstring was not clear? >>> >>> Well >>> | org-export-dispatch is an interactive compiled Lisp function in >>> | ‘ox.el’. >>> | >>> | (org-export-dispatch ARG) >>> ... >>> >>> Does not mention, that a selected region gets exported. >> >> Fair enough. >> Ironically, it is not even wrong. Looking at the source code, respecting >> region is merely a convention coming from most of backends calling >> `org-export-as'. >> >> As one possibility, we can add something like the following to the >> docstring: >> >> "Usually, exporting respects current narrowing and active region, though >> individual export backends might not follow the convention. See >> `org-export-as' for more details." >> >> Alternatively, we can modify `org-export-define-backend' to change the >> docstring with links to individual backend exporters. >> >> Or we may modify the dispatcher menu to indicate active region. Though >> it is not guaranteed to be obeyed by the backends. >> >> Best, >> Ihor >> >> > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: export regions of a org files to other formats (most likely only to a buffer).
i would say that respecting narrowing is expected in emacs, as a kind of pseudo-buffer bob/eob, so it would be surprising to find that it might not be so in a part of org. lack of it should be mentioned, but might be a bug. On 5/25/22, Ihor Radchenko wrote: > Uwe Brauer writes: > >>> Could you please clarify which part of the function docstring was not >>> clear? >> >> Well >> | org-export-dispatch is an interactive compiled Lisp function in >> | ‘ox.el’. >> | >> | (org-export-dispatch ARG) >> ... >> >> Does not mention, that a selected region gets exported. > > Fair enough. > Ironically, it is not even wrong. Looking at the source code, respecting > region is merely a convention coming from most of backends calling > `org-export-as'. > > As one possibility, we can add something like the following to the > docstring: > > "Usually, exporting respects current narrowing and active region, though > individual export backends might not follow the convention. See > `org-export-as' for more details." > > Alternatively, we can modify `org-export-define-backend' to change the > docstring with links to individual backend exporters. > > Or we may modify the dispatcher menu to indicate active region. Though > it is not guaranteed to be obeyed by the backends. > > Best, > Ihor > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: Opening org-cite links with different application
"Bruce D'Arcus" writes: > On Wed, May 25, 2022 at 12:47 PM Max Nikulin wrote: > >> I have had a quick glance into the code I have an additional question >> why `browse-url' is not used for `citar-file-open-external'. > > The "external" here means opening files external to emacs. > > The typical use case is someone wanting to use a system PDF or image viewer. > > I had actually forgotten about that function when initially replying! > The browse-url library could be a good approach. It does support external applications and from memory, can be configured based on MIME type and supports both primary and secondary renderer selection (at least for html). Ability to easily switch between internal/external rendering could be very useful.
Custom beamer blocks for pros and cons list
Hi.
I am adapting this example:
--8<---cut here---start->8---
https://tex.stackexchange.com/questions/28760/custom-beamer-blocks-for-pros-and-cons
--8<---cut here---end--->8---
This is my file:
--8<---cut here---start->8---
#+AUTHOR: Me
#+EMAIL:
#+DATE: 2022
#+DESCRIPTION:
#+KEYWORDS:
#+OPTIONS: toc:nil
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+startup: beamer
#+LaTeX_CLASS: beamer
#+LATEX_CLASS_OPTIONS: [bigger]
#+BEAMER_FRAME_LEVEL: 2
#+COLUMNS: %40ITEM %10BEAMER_env(Env) %9BEAMER_envargs(Env Args)
%4BEAMER_col(Col) %10BEAMER_extra(Extra)
#+LaTeX_Header: \beamertemplatenavigationsymbolsempty
#+LaTeX_Header: \newenvironment<>{problock}[1]{%
#+LaTeX_Header: \begin{actionenv}#2%
#+LaTeX_Header: \def\insertblocktitle{#1}%
#+LaTeX_Header: \par%
#+LaTeX_Header: \mode{%
#+LaTeX_Header: \setbeamercolor{block
title}{fg=white,bg=orange!20!black}
#+LaTeX_Header:\setbeamercolor{block body}{fg=black,bg=olive!50}
#+LaTeX_Header:\setbeamercolor{itemize item}{fg=orange!20!black}
#+LaTeX_Header:\setbeamertemplate{itemize item}[triangle]
#+LaTeX_Header: }%
#+LaTeX_Header: \usebeamertemplate{block begin}}
#+LaTeX_Header: {\par\usebeamertemplate{block end}\end{actionenv}}
** Comparisson
:PROPERTIES:
:BEAMER_envargs: [t]
:END:
*** Pros :BMCOL:B_block:
:PROPERTIES:
:BEAMER_col: 0.45
:BEAMER_env: block
:END:
#+begin_problock
- New.
- Other Pro.
- Additional Pro.
#+end_problock
*** Cons :BMCOL:B_block:
:PROPERTIES:
:BEAMER_col: 0.4
:BEAMER_env: block
:BEAMER_envargs: <2->
:END:
- Need Testing.
- Other Con.
- More Con.
--8<---cut here---end--->8---
I am getting an error and PDF is not generated.
Thanks.
About opening issues vs email [Was: About 'inline special blocks']
On Thu, May 26, 2022 at 1:36 PM João Pedro wrote: > > On Thu, May 26 2022 20:20, Ihor Radchenko wrote: > > > I think that you can simply open an issue in his Github repo. > > I reached out to him on e-mail, if he doesn't reply there I'll create > the issue. Thanks! Just saying this based on my personal preference. I would rather prefer that people directly open an issue on Github than emailing me personally. Reasons: - Issues section is there for a reason. If the repo owner did not like people opening Issues, they would disable that section. - Conversations and discussions are better formatted and readable in the issue threads. - If the feature is implemented, I like to link that commit or PR to that issue so that the entire history and reasoning behind a feature addition (esp. if it's a breaking one) can be followed through hyperlinks from the commit log to the issue thread.
Re: export regions of a org files to other formats (most likely only to a buffer).
>>> "IR" == Ihor Radchenko writes: > Uwe Brauer writes: >>> Could you please clarify which part of the function docstring was not >>> clear? >> >> Well >> | org-export-dispatch is an interactive compiled Lisp function in >> | ‘ox.el’. >> | >> | (org-export-dispatch ARG) >> ... >> >> Does not mention, that a selected region gets exported. > Fair enough. > Ironically, it is not even wrong. Looking at the source code, respecting > region is merely a convention coming from most of backends calling > `org-export-as'. > As one possibility, we can add something like the following to the > docstring: > "Usually, exporting respects current narrowing and active region, though > individual export backends might not follow the convention. See > `org-export-as' for more details." I think this is fine, at least for me. Not sure what others think. -- I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the ban of Russia from SWIFT. I support the EU membership of the Ukraine. smime.p7s Description: S/MIME cryptographic signature
Allow Currency Symbols and Grouping Commas in Table Numbers
I often use org table to perform calculations and export those tables to LaTeX documents. One thing I always wished I could do with org tables is get it to allow numbers to be decorated with currency symbols, the dollar, euro, yen, etc., as well as grouping commas so that the tables are more suitable for presentation. I can see from the code that there is a function, org-table--number-for-summing, that converts text into numbers for summing, and it would seem it could strip out leading or trailing currency symbols as well as grouping commas before submitting numbers to calc for calculation. Consider this a feature request. I think it would be a very popular enhancement to org. Regards, -- Daniel E. Doherty Law Offices of Daniel E. Doherty 7300 W. 110th Street, Suite 930 Overland Park, KS 66210 913.338.7182 (Phone) 913.338.7164 (FAX) d...@ddoherty.net
Re: Opening org-cite links with different application
On Wed, May 25, 2022 at 12:47 PM Max Nikulin wrote: > I have had a quick glance into the code I have an additional question > why `browse-url' is not used for `citar-file-open-external'. The "external" here means opening files external to emacs. The typical use case is someone wanting to use a system PDF or image viewer. I had actually forgotten about that function when initially replying! Bruce
Re: [tip] org-publish to work with (very) large books
Thanks, Juan!
Yours,
Christian
Juan Manuel Macías writes:
> Hi Ihor and Christian,
>
> Ihor Radchenko writes:
>
>> Christian Moe writes:
>>
>>> Do I understand correctly that the main advantage of this approach (over
>>> #+INCLUDE) is the ability to continuously update preview of the whole
>>> book with latexmk -pvc even if you only re-export one chapter from
>>> Org-mode?
>>
>> I am not sure why Juan did not use include. Include would not require
>> LaTeX to re-compile unchanged files. See
>> https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include
>>
>>> I couldn't find the :body-only publishing option in the docs ...?
>>
>> See [[info:org#The Export Dispatcher][org#The Export Dispatcher]]
>>
>> Best,
>> Ihor
>>
>
> Sorry for not explaining the \input part in more detail. I think the
> essential part here is that all the .tex files (the subdocuments) are
> already created by org-publish before I compile the master document. The
> master document simply stores all the subdocuments: I use
> \input{subdocument.tex} instead of the org #+INCLUDE directive (not the
> LaTeX \include command). The master document calls ready-made TeX files,
> not Org files. And it is independent of the whole org-publish process,
> which is responsible for creating only the parts of the book. This
> procedure, apart from being able to compile parts of the book in real
> time with latexmk -pvc, allows me to have more control over these parts.
> But it makes more sense to use it when dealing with very long books. The
> first time I used it was in a book of more than 1000 pages :-)
>
> The skeleton of the process is that subdocuments are produced with
> org-publish (as uncompiled tex files) and the master document is
> exported to tex from org and then compiled with latexmk inside /tex
> directory.
>
> Best regards,
>
> Juan Manuel
Re: About 'inline special blocks'
On Thu, May 26 2022 20:20, Ihor Radchenko wrote: > I think that you can simply open an issue in his Github repo. I reached out to him on e-mail, if he doesn't reply there I'll create the issue. Thanks! -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Change in `org-cycle-hook' breaks behavior
In Org 9.5, `org-cycle-hook' includes `org-cycle-hide-drawers', which hides the drawer after opening the contents of a headline with `org-cycle'. However, if you removed `org-cycle-hide-drawers' from the hook, `org-cycle' would show you the drawers (at least the PROPERTIES one). I relied on this behavior, as I wanted the drawers to be shown when I opened a headline. In Org 9.6 the hook does no longer include `org-cycle-hide-drawers', and this change is mentioned in the NEWS file. The new default behavior is to show a drawer iff it was opened previously. This is fine, but I don't see an easy change to resurrect my previously configuration wiht Org 9.6. Maybe a function `org-cycle-show-drawers' could be added? Implicitly it seems like `org-cycle' previously did contain this functionality. Adding such a function to `org-cycle-hook' would solve my problem.
Re: [BUG] org-open-file immediately termininates when calling xdg-open that calls emacsclient
On 26/05/2022 21:24, Ihor Radchenko wrote: Max Nikulin writes: Try the following: (start-process-shell-command "1" nil "emacsclient -c ~/.bashrc") (let ((process-connection-type nil)) (start-process-shell-command "1" nil "emacsclient -c ~/.bashrc")) The second command will cause flickering, though opens the file in the same frame (not the new as one would expect from -c switch). Both commands creates a new frame in Emacs-26 and Emacs-27. I have not tried 28 yet. You may try if the following works for you (borrowed from `browse-url-xdg-open') (let ((url "~/.bashrc")) (call-process "xdg-open" nil 0 nil url)) Such approach has an advantage: viewer remains running after exit from Emacs. You may submit an emacs bug for `mailcap-view-file' that should have similar behavior. P.S. I still believe that Emacs configuration for mailcap.el is broken if external handler is invoked from Emacs just to execute emacsclient. On the other hand it should not lead to Emacs crash.
Proposal: 'executable' org-capture-templaes
Hi guys,
I was playing with org-capture today, and it strike me that it could be used as
a simple and lightweight alternative to create GUIs for user options, somewhat
resembling the use of well-known hydra/transient or built-in help macro or easy
menu.
I would like to propose a small 'feature/change' to org-capture templates, to
inlude a new target: 'exec'. It should be followed by a function to be
executed.
I believe that this is a simple change that does not intrude on anything else in
org-capture, you can see the attached patch. The goal is to just circumwent the
createion of capture buffer, bookmark and other processing done by org-capture
etc. However there might be things I am not aware of, so if someone have more
insight, it is welcomed to hear.
There is a small illustration in the attached patch as well.
The error handling could probably be much better, so I would like to hear
opinion and suggestion how can I improve it.
best regards
/arthur
>From b8a910235c688d9ea1cb717a186699da489987af Mon Sep 17 00:00:00 2001
From: Arthur Miller
Date: Thu, 26 May 2022 17:15:37 +0200
Subject: [PATCH] Introduce 'executable' org-capture-templates
* etc/ORG-NEWS: Documented new feature.
* doc/misc/org.org: Documented new template target.
* lisp/org/org-capture.el: 'org-capture' add handler for 'exec' target.
---
doc/misc/org.org| 14 ++
etc/ORG-NEWS| 28
lisp/org/org-capture.el | 5 +
3 files changed, 47 insertions(+)
diff --git a/doc/misc/org.org b/doc/misc/org.org
index 3dce83c936..2445c57942 100644
--- a/doc/misc/org.org
+++ b/doc/misc/org.org
@@ -7629,6 +7629,20 @@ Now lets look at the elements of a template definition. Each entry in
the target entry or as a top-level entry. The target file should
be an Org file.
+ - ~exec~ ::
+
+An executable function. Function will be executed and the result
+returned immidiately. No further processing by org-capture will be
+performed, no capture buffer will be created, no last capture
+bookmark etc, will be created. The eventual other template
+parameters are ignored. Use this when you need to execute a Lisp
+function for the side effects. Useful if you would like to create
+lightweight GUIs for user choices based on org-capture mechanism.
+
+Simple example:
+
+'("h" "Say hello" exec (lambda () (message "Hello, World!")))
+
- ~item~ ::
A plain list item, placed in the first plain list at the target
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 37a39131d9..53ac10ba45 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -108,6 +108,34 @@ If you prefer to keep the keybinding, you can add it back to
#+end_src
** New features
+*** 'Executable' org-capture-templates
+
+New target, "exec" is added to templates which provides an easy option
+to run a function from within org-capture dialog. It is meant as a
+lightweight option to create GUIs for user options based on
+org-capture mechanism.
+
+Exec should be followed by a lisp function, a lambda or a function
+object that will be executed and result returned without further
+processing by org-capture. As a consequence other template parameters
+are not used with this target.
+
+Illustration:
+
+#+begin_src emacs-lisp
+(defvar my-templates
+ `(("h" "Hello World" exec
+ (lambda ()
+ (message "Hello, World")))
+("f" "Find file" exec ,(function find-file
+
+(defun simple-menu ()
+ (interactive)
+ (let ((org-capture-templates my-templates))
+(org-capture)))
+
+(define-key global-map (kbd "C-S-n") #'simple-menu)
+#+end_src
*** New citation engine
diff --git a/lisp/org/org-capture.el b/lisp/org/org-capture.el
index 2fd9a9c74d..1a9b59de2f 100644
--- a/lisp/org/org-capture.el
+++ b/lisp/org/org-capture.el
@@ -665,6 +665,11 @@ org-capture
(remove-text-properties 0 (length annotation)
'(read-only t) annotation))
(cond
+ ((equal (nth 2 entry) 'exec)
+(let ((f (plist-get entry 'exec)))
+ (if (not f) (error "Missing function specification.")
+(if (commandp f) (call-interactively f)
+ (if (functionp f) (funcall f) (error "Invalid function specification."))
((equal entry "C")
(customize-variable 'org-capture-templates))
((equal entry "q")
--
2.36.1
Re: [BUG] org-open-file immediately termininates when calling xdg-open that calls emacsclient
Max Nikulin writes: >> They both set process-connection-type to nil/'pipe. Somehow, this change >> breaks org-open-file for me when org-open-file calls xdg-open and xdg is >> confugured to open the file with emacsclient. I only see a flicker and >> the file does not open. Sometimes, Emacs even crashes. > > I can not reproduce a problem, however I tried to factor-out xdg-open. > Emacs-27.1, a minimal LXC container, so "&" to simulate kde-open5 > starting process in background. On the other hand I consider behavior > when emacsclient is called from emacs as confusing due to requirement of > C-x # to notify emacs about completion. Try the following: (start-process-shell-command "1" nil "emacsclient -c ~/.bashrc") (let ((process-connection-type nil)) (start-process-shell-command "1" nil "emacsclient -c ~/.bashrc")) The second command will cause flickering, though opens the file in the same frame (not the new as one would expect from -c switch). To reproduce what I am seeing, you may need to adjust xdg- database adding the following .desktop file: ~/.local/share/applications/emacsclient-local.desktop --- [Desktop Entry] Type=Application Version=1.0 Name=Emacs Client Exec=emacsclient -c %f Icon=emacs-icon Terminal=false MimeType=text/css;text/english;text/html;text/plain;text/x-c;text/x-chdr;text/x-csrc;text/x-c++;text/x-c++hdr;text/x-c++src;text/x-java;text/x-makefile;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;application/pdf;inode/directory;inode/mount-point;image/png;image/tiff; --- Then, make sure that xdg-open uses the desktop file for application/x-shellscript (xdg-mime query default application/x-shellscript) Finally, run (start-process-shell-command "1" nil "xdg-open -c ~/.bashrc") (let ((process-connection-type nil)) (start-process-shell-command "1" nil "xdg-open -c ~/.bashrc")) Observe flickering + Emacs not opening the file. > Do you see the same problem for a function from mailcap.el in the > development emacs version? Which function are you referring to? Best, Ihor
Re: [tip] org-publish to work with (very) large books
Christian Moe writes: > I see, thanks. > > Ought this to be documented at [[info:org#Publishing options]], perhaps? Maybe. I think org-publish-project-alist docstring has many more details. Someone™ should update the manual. Patches are welcome :) Best, Ihor
Re: [tip] org-publish to work with (very) large books
Hi Ihor and Christian,
Ihor Radchenko writes:
> Christian Moe writes:
>
>> Do I understand correctly that the main advantage of this approach (over
>> #+INCLUDE) is the ability to continuously update preview of the whole
>> book with latexmk -pvc even if you only re-export one chapter from
>> Org-mode?
>
> I am not sure why Juan did not use include. Include would not require
> LaTeX to re-compile unchanged files. See
> https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include
>
>> I couldn't find the :body-only publishing option in the docs ...?
>
> See [[info:org#The Export Dispatcher][org#The Export Dispatcher]]
>
> Best,
> Ihor
>
Sorry for not explaining the \input part in more detail. I think the
essential part here is that all the .tex files (the subdocuments) are
already created by org-publish before I compile the master document. The
master document simply stores all the subdocuments: I use
\input{subdocument.tex} instead of the org #+INCLUDE directive (not the
LaTeX \include command). The master document calls ready-made TeX files,
not Org files. And it is independent of the whole org-publish process,
which is responsible for creating only the parts of the book. This
procedure, apart from being able to compile parts of the book in real
time with latexmk -pvc, allows me to have more control over these parts.
But it makes more sense to use it when dealing with very long books. The
first time I used it was in a book of more than 1000 pages :-)
The skeleton of the process is that subdocuments are produced with
org-publish (as uncompiled tex files) and the master document is
exported to tex from org and then compiled with latexmk inside /tex
directory.
Best regards,
Juan Manuel
Re: [tip] org-publish to work with (very) large books
I see, thanks. Ought this to be documented at [[info:org#Publishing options]], perhaps? Yours, Christian Ihor Radchenko writes: > Christian Moe writes: > >> Do I understand correctly that the main advantage of this approach (over >> #+INCLUDE) is the ability to continuously update preview of the whole >> book with latexmk -pvc even if you only re-export one chapter from >> Org-mode? > > I am not sure why Juan did not use include. Include would not require > LaTeX to re-compile unchanged files. See > https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include > >> I couldn't find the :body-only publishing option in the docs ...? > > See [[info:org#The Export Dispatcher][org#The Export Dispatcher]] > > Best, > Ihor
Re: [tip] org-publish to work with (very) large books
Christian Moe writes: > Do I understand correctly that the main advantage of this approach (over > #+INCLUDE) is the ability to continuously update preview of the whole > book with latexmk -pvc even if you only re-export one chapter from > Org-mode? I am not sure why Juan did not use include. Include would not require LaTeX to re-compile unchanged files. See https://tex.stackexchange.com/questions/246/when-should-i-use-input-vs-include > I couldn't find the :body-only publishing option in the docs ...? See [[info:org#The Export Dispatcher][org#The Export Dispatcher]] Best, Ihor
Re: [tip] org-publish to work with (very) large books
Thanks for this, really interesting.
Do I understand correctly that the main advantage of this approach (over
#+INCLUDE) is the ability to continuously update preview of the whole
book with latexmk -pvc even if you only re-export one chapter from
Org-mode?
I couldn't find the :body-only publishing option in the docs ...?
Yours,
Christian
Juan Manuel Macías writes:
> Hi all,
>
> - tl; dr: I describe here my workflow with org-publish to work with long
> books.
>
> —
>
> I discovered a long time ago that `org-publish' not only works very well
> for managing websites but also for working with long and complex books
> with many parts, with output to LaTeX/PDF. I developed a workflow around
> it that has been quite productive for me, and that I briefly describe
> here in case someone finds it useful and wants to try it or modify/adapt
> it to their needs. I usually use it for my typesetting work, but I think
> it can also be useful for personal projects, such as doctoral theses.
>
> First of all, each folder of my project-books has the same structure:
> two subdirectories named `/org' and `/tex', for the source `org' files
> and for the output `.tex' documents, respectively. And, inside the `org'
> directory I include a `setup' file, an `elisp' file (for export
> filters), and another `/img' directory for image files. Each `org' file
> is a part of the book, and usually begins simply with the directives:
>
> ┌
> │ #+SETUPFILE: xxx.setup
> │ #+INCLUDE: "elisp"
> └
>
> `Org-publish' exports the subdocuments (body only!) as `.tex' documents
> in the `/tex' folder, but they are not compiled.
>
> What gets compiled is a master `.org' file, which is also inside the
> `org' folder. I compile this master file using an asynchronous function
> that calls `latexmk'. I put all the LaTeX configuration, the packages to
> load, the (re)defined commands and macros, the necessary Lua code, etc.
> in a `.sty' file that I load at the very beginning of the master
> document. Subdocuments are loaded into this file by the LaTeX command
> (\input), not by the org #+INCLUDE directive. So the master file usually
> looks like this:
>
> ┌
> │ #+LaTeX_CLASS: my-custom-latex-class
> │ #+LaTeX_Header: \input{my-custom-conf.sty}
> │ #+SETUPFILE: .setup
> │ #+INCLUDE: "elisp"
> │
> │ * Part 1
> │ ** Chapter 1
> │ #+LaTeX: \input{chapter1.tex}
> └
>
> When I eval my function, `latexmk' compiles the entire book with the
> `-pvc' option, which keeps the session open, and if it detects any
> changes to the entire document, it recompiles and refresh the pdf view.
> For example, if I edit one of the subdocuments and run
> `org-publish-current-file', everything is automatically recompiled.
>
> When I have the project folder ready, I add this to
> `org-publish-project-alist' (this is an example from one of the books I
> did recently):
>
> ┌
> │ ("cartas-org"
> │ :base-directory "~/Git/cartas/libro/org/"
> │ :base-extension "org"
> │ ;; Directorio para los ficheros *.tex
> │ :publishing-directory "~/Git/cartas/libro/tex/"
> │ :publishing-function org-latex-publish-to-latex
> │ :body-only t ;; this is important!
> │ :exclude "cartas-master\\.org\\|bibliografia-cartas\\.org"
> │ :recursive t)
> │
> │ ("cartas-img"
> │ :base-directory "~/Git/cartas/libro/org/img/"
> │ :base-extension "jpg\\|png"
> │ :publishing-directory "~/Git/cartas/libro/tex/img/"
> │ :recursive t
> │ :publishing-function org-publish-attachment)
> │
> │ ("cartas" :components ("cartas-tex" "cartas-img"))
> └
>
> And finally, this is the function that compiles everything (each project
> usually has some local variables, like the value of ’jobname’ or the
> status of the printing proofs).
>
> Nota Bene: The reason for using async is that in some projects,
> especially bilingual editions, I need to pre-compile some files first.
> Under normal conditions I don't think it's necessary to use async, since
> org-publish just exports everything to .tex documents (short timeout)
> and then start-process-shell-command run latexmk asynchronously.
>
> Best regards,
>
> Juan Manuel
>
> ┌
> │ (require 'async)
> │ (require 'projectile)
> │
> │ (defun latexmk-compile-project-async ()
> │ (interactive)
> │ (let*
> │ ((project-root (projectile-project-root))
> │(master-file (read-file-name "Compile: "
> │ (concat project-root "libro/org/")))
> │(master-file-tex (file-name-sans-extension
> │ (expand-file-name master-file)))
> │(dir-tex (file-name-directory
> │ (expand-file-name
> │ (replace-regexp-in-string "/org/" "/tex/" master-file)
> │ ;; save the master document
> │ (with-current-buffer
> │ (find-file-noselect master-file)
> │ (save-buffer))
> │ (async-start
> │ (lambda ()
> │(load "~/.emacs")
> │(with-current-buffer
> │(find-file-noselect master-file)
> │ (org-show-all)
> │
Re: About 'inline special blocks'
João Pedro writes: >> I am not sure if I mentioned this earlier, but org-special-block-extras >> could be a good addition to Org core. > > Has anyone tried reaching out to the author? I think it would be a great > addition! It is a seemingly simple idea that opens up some many > possibilities in Org-mode. If I recall correctly, it was one of the comments (or questions) when he presented during Emacsconf. However, I do not recall him asking about anything on Org mailing list. I think that you can simply open an issue in his Github repo. Best, Ihor
Re: re-scanning bibliography for org-cite
Timothy writes: > Hi Eric, > >> The difficulty will be knowing whether they work or not given the sporadic >> nature of the problem… > > If it’s any help, I consistently have this issue when producing the bib file > by tangling. Then, can you also try the proposed steps? If you can reproduce the problem consistently, you can reveal what helps (or not) far quicker. Best, Ihor
Re: re-scanning bibliography for org-cite
Hi Eric, > The difficulty will be knowing whether they work or not given the sporadic > nature of the problem… If it’s any help, I consistently have this issue when producing the bib file by tangling. All the best, Timothy
Re: About 'inline special blocks'
On Thu, May 26 2022 12:56, Ihor Radchenko wrote: > I agree. But it is a known problem on defining new specific command vs. > running a new generic command with arguments. You can indeed define a > new command (block in our case), but if you just need to adjust some > parameter once in the whole document, there is no point creating a whole > new block type just for that purpose. Think about defun vs. lambda. Oh, got it. Well, as I said, I'd be more than happy using the #+attr_X solution though! > I am not sure if I mentioned this earlier, but org-special-block-extras > could be a good addition to Org core. Has anyone tried reaching out to the author? I think it would be a great addition! It is a seemingly simple idea that opens up some many possibilities in Org-mode. Best, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: re-scanning bibliography for org-cite
Hi Ihor, I will try these out, hopefully tomorrow. The difficulty will be knowing whether they work or not given the sporadic nature of the problem... Thank you, eric -- : Eric S Fraga, with org release_9.5.3-513-g292116 in Emacs 29.0.50
Re: [BUG] org-element--cache: Unregistered buffer modifications detected saving org-agenda-files buffers [9.5.3 (9.5.3-g8e69ad @ /Users/enrikes/.emacs.d/straight/build/org/)]
Adding Org mode mailing list back to CC. Please, use Reply All when replying next time, unless you specifically want to keep the exchange not public. Enrique Kessler Martínez writes: > Yes, here are two of the warnings I usually get. I get one of those for > each of the files that are part of the org-agenda-files when saving. > > Warning (org-element-cache): org-element--cache: Unregistered buffer > modifications detected. Resetting. > If this warning appears regularly, please report the warning text to Org > mode mailing list (M-x org-submit-bug-report). > The buffer is: inbox_review.org > Current command: (org-save-all-org-buffers 4 5) > Chars modified: 4 > Buffer modified: 5 > Backtrace: > nil Disable showing Disable logging Thanks! So, something appears to alter Org buffers on loading. This usually happens because of misbehaving third-party packages. Do you happen to use valign? If so, will the warning disappear if you disable this package? Otherwise, can you try to reproduce the problem without loading your configuration or loading it minimally? See https://orgmode.org/manual/Feedback.html Best, Ihor
Re: re-scanning bibliography for org-cite
Eric S Fraga writes: > Is there a function I can call to force a rescan? That would satisfy me > as I could put it into a hook for org-bibtex (or advice the function if > no hook available). The relevant function is org-cite-basic--parse-bibliography. You can try 2 things: 1. Set org-cite-basic--file-id-cache to nil in :around advice before calling the function 2. Remove :cite-basic/bibliography from INFO plist in :around advice before calling the function I you find any of these methods helpful, please report back. I have a suspicion that :cite-basic/bibliography might be the cause. Best, Ihor
Re: [BUG] org-element--cache: Unregistered buffer modifications detected saving org-agenda-files buffers [9.5.3 (9.5.3-g8e69ad @ /Users/enrikes/.emacs.d/straight/build/org/)]
Enrique Kessler Martínez writes: > I'm running into the Unregistered buffer modifications bug in the past few > weeks. The current workflow that causes it is: > - Open org-agenda. > - Trigger org-save-all-buffers. Thanks for the report! Could you please share the full text of the warning? The warning should contain multiple lines with diagnostic information. Best, Ihor
[tip] org-publish to work with (very) large books
Hi all,
- tl; dr: I describe here my workflow with org-publish to work with long
books.
—
I discovered a long time ago that `org-publish' not only works very well
for managing websites but also for working with long and complex books
with many parts, with output to LaTeX/PDF. I developed a workflow around
it that has been quite productive for me, and that I briefly describe
here in case someone finds it useful and wants to try it or modify/adapt
it to their needs. I usually use it for my typesetting work, but I think
it can also be useful for personal projects, such as doctoral theses.
First of all, each folder of my project-books has the same structure:
two subdirectories named `/org' and `/tex', for the source `org' files
and for the output `.tex' documents, respectively. And, inside the `org'
directory I include a `setup' file, an `elisp' file (for export
filters), and another `/img' directory for image files. Each `org' file
is a part of the book, and usually begins simply with the directives:
┌
│ #+SETUPFILE: xxx.setup
│ #+INCLUDE: "elisp"
└
`Org-publish' exports the subdocuments (body only!) as `.tex' documents
in the `/tex' folder, but they are not compiled.
What gets compiled is a master `.org' file, which is also inside the
`org' folder. I compile this master file using an asynchronous function
that calls `latexmk'. I put all the LaTeX configuration, the packages to
load, the (re)defined commands and macros, the necessary Lua code, etc.
in a `.sty' file that I load at the very beginning of the master
document. Subdocuments are loaded into this file by the LaTeX command
(\input), not by the org #+INCLUDE directive. So the master file usually
looks like this:
┌
│ #+LaTeX_CLASS: my-custom-latex-class
│ #+LaTeX_Header: \input{my-custom-conf.sty}
│ #+SETUPFILE: .setup
│ #+INCLUDE: "elisp"
│
│ * Part 1
│ ** Chapter 1
│ #+LaTeX: \input{chapter1.tex}
└
When I eval my function, `latexmk' compiles the entire book with the
`-pvc' option, which keeps the session open, and if it detects any
changes to the entire document, it recompiles and refresh the pdf view.
For example, if I edit one of the subdocuments and run
`org-publish-current-file', everything is automatically recompiled.
When I have the project folder ready, I add this to
`org-publish-project-alist' (this is an example from one of the books I
did recently):
┌
│ ("cartas-org"
│ :base-directory "~/Git/cartas/libro/org/"
│ :base-extension "org"
│ ;; Directorio para los ficheros *.tex
│ :publishing-directory "~/Git/cartas/libro/tex/"
│ :publishing-function org-latex-publish-to-latex
│ :body-only t ;; this is important!
│ :exclude "cartas-master\\.org\\|bibliografia-cartas\\.org"
│ :recursive t)
│
│ ("cartas-img"
│ :base-directory "~/Git/cartas/libro/org/img/"
│ :base-extension "jpg\\|png"
│ :publishing-directory "~/Git/cartas/libro/tex/img/"
│ :recursive t
│ :publishing-function org-publish-attachment)
│
│ ("cartas" :components ("cartas-tex" "cartas-img"))
└
And finally, this is the function that compiles everything (each project
usually has some local variables, like the value of ’jobname’ or the
status of the printing proofs).
Nota Bene: The reason for using async is that in some projects,
especially bilingual editions, I need to pre-compile some files first.
Under normal conditions I don't think it's necessary to use async, since
org-publish just exports everything to .tex documents (short timeout)
and then start-process-shell-command run latexmk asynchronously.
Best regards,
Juan Manuel
┌
│ (require 'async)
│ (require 'projectile)
│
│ (defun latexmk-compile-project-async ()
│ (interactive)
│ (let*
│ ((project-root (projectile-project-root))
│(master-file (read-file-name "Compile: "
│ (concat project-root "libro/org/")))
│(master-file-tex (file-name-sans-extension
│(expand-file-name master-file)))
│(dir-tex (file-name-directory
│(expand-file-name
│ (replace-regexp-in-string "/org/" "/tex/" master-file)
│ ;; save the master document
│ (with-current-buffer
│ (find-file-noselect master-file)
│ (save-buffer))
│ (async-start
│ (lambda ()
│(load "~/.emacs")
│(with-current-buffer
│ (find-file-noselect master-file)
│(org-show-all)
│(save-buffer)
│(org-latex-export-to-latex nil nil nil nil nil))
│;; remove all old auxiliary files before compiling
│(shell-command (concat "rm -r " dir-tex (file-name-base
master-file-tex) "*"))
│(shell-command (concat "mv " master-file-tex ".tex" " " dir-tex))
│"Document exported")
│ (lambda (resultado)
│(message resultado)
│(let
│ ((default-directory dir-tex)
│ (jobname (if (and jobname-local printing-proofs-state)
│(concat jobname-local "_" printing-proofs-state
Re: re-scanning bibliography for org-cite
On Thursday, 26 May 2022 at 13:00, Ihor Radchenko wrote: > In theory, it might be related to one of the changes I made in this > area. I am not 100% sure, but bibliography might not be rescanned if you > edit a bibliography file in Emacs buffer, but do not actually save it. > Is this what is happening? No and, to be fair, I wouldn't expect the scanning to take place if I hadn't saved the file. I have my bibliography in an org file which I export to .bib using org-bibtex. Is there a function I can call to force a rescan? That would satisfy me as I could put it into a hook for org-bibtex (or advice the function if no hook available). Thank you, eric -- : Eric S Fraga, with org release_9.5.3-472-gd2a459 in Emacs 29.0.50
[BUG] org-element--cache: Unregistered buffer modifications detected saving org-agenda-files buffers [9.5.3 (9.5.3-g8e69ad @ /Users/enrikes/.emacs.d/straight/build/org/)]
Hi there!
I'm running into the Unregistered buffer modifications bug in the past few
weeks. The current workflow that causes it is:
- Open org-agenda.
- Trigger org-save-all-buffers.
After that, the warnings appear. I build the org-agenda files automatically
with a query for PROJECT tags on my org-roam directory. I set that up using
this post, that might help debugging:
https://d12frosted.io/posts/2021-01-16-task-management-with-roam-vol5.html
Thank you for your work!
Best,
Quique.
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 29.0.50 (build 1, x86_64-apple-darwin19.6.0, NS
appkit-1894.60 Version 10.15.7 (Build 19H1824))
of 2022-05-05
Package: Org mode version 9.5.3 (9.5.3-g8e69ad @
/Users/enrikes/.emacs.d/straight/build/org/)
current state:
==
(setq
org-agenda-prefix-format " %?-12t% s"
org-archive-location "~/Documents/org_files/archive/%s_archive::"
org-roam-db-location "/Users/enrikes/.emacs.d/var/org/org-roam.db"
org-link-elisp-confirm-function 'yes-or-no-p
org-shiftdown-final-hook '(evil-org-shift-fallback-command)
org-directory "~/Documents/org_files"
org-after-refile-insert-hook '(qk-org-clean-tags)
org-hide-emphasis-markers t
org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-pdftools-get-desc-function 'org-pdftools-get-desc-default
org-agenda-custom-commands '(("d" "Agenda"
((agenda ""
((org-agenda-overriding-header "Today's
Schedule:") (org-agenda-span 'day) (org-agenda-ndays 1)
(org-agenda-start-on-weekday nil) (org-agenda-start-day "+0d")
(org-agenda-skip-function '(cond ((equal
(file-name-nondirectory (buffer-file-name)) "refile.org")
(outline-next-heading) (1- (point))) (t (org-agenda-skip-entry-if 'todo
'done
(org-agenda-todo-ignore-deadlines nil))
)
(todo "PROJECT"
((org-agenda-overriding-header "Project list:")
(org-tags-match-list-sublevels nil))) (tags "REFILING"
((org-agenda-overriding-header "Tasks to Refile:")
(org-tags-match-list-sublevels nil)))
(todo "TODO" ((org-agenda-overriding-header
"Unscheduled Tasks:") (org-tags-match-list-sublevels nil)
(org-agenda-skip-function '(org-agenda-skip-entry-if 'deadline
'scheduled
(todo "WAITING|SOMEDAY"
((org-agenda-overriding-header "Waiting/Someday Tasks:")
(org-tags-match-list-sublevels nil))) (todo "NOTE"
((org-agenda-overriding-header "Notes:") (org-tags-match-list-sublevels
nil)))
(agenda ""
((org-agenda-overriding-header
"Upcoming:") (org-agenda-span 7) (org-agenda-start-day "+1d")
(org-agenda-start-on-weekday nil)
(org-agenda-skip-function '(cond ((equal
(file-name-nondirectory (buffer-file-name)) "refile.org")
(outline-next-heading) (1- (point))) (t (org-agenda-skip-entry-if 'todo
'done
(org-agenda-todo-ignore-deadlines nil))
)
)
)
)
org-agenda-files '("/Users/enrikes/Documents/slipbox/pages/
amazon_meetings.org" "/Users/enrikes/Documents/slipbox/pages/
nabyinotifications_push_notifications_channels_not_showing.org"
"/Users/enrikes/Documents/slipbox/pages/nabyi_cgp.org"
"/Users/enrikes/Documents/slipbox/pages/book_list.org"
"/Users/enrikes/Documents/slipbox/pages/ramping_up_to_the_team.org"
"/Users/enrikes/Documents/slipbox/pages/
deep_dive_on_the_google_billing_project.org"
"/Users/enrikes/Documents/slipbox/pages/
notifications_spike_add_tests_for_the_android_12_migration.org"
"/Users/enrikes/Documents/slipbox/pages/
nabyinotifications_monitor_the_notifications_post_merge_on_the_r9_release.org
"
"/Users/enrikes/Documents/slipbox/pages/
nabyinotifications.org" "/Users/enrikes/Documents/slipbox/pages/
life_items.org" "/Users/enrikes/Documents/slipbox/pages/inbox_review.org"
"/Users/enrikes/Documents/slipbox/pages/anki.org"
"/Users/enrikes/Documents/slipbox/pages/
follow_up_review.org" "/Users/enrikes/Documents/slipbox/pages/meetings.org"
"/Users/enrikes/Documents/slipbox/pages/
nabyinotifications_oncall_shadowing.org"
"/Users/enrikes/Documents/slipbox/pages/
nabyinotifications_uncertified_orange_app_in_production_needs_to_be_certified_or_deprecated.org
")
org-capture-templates '(("#" "used by gnus-icalendar-org" entry (file+olp
Re: Trouble producing nicely aligned org tables from emacs-jupyter code blocks using latest org version
I’d be happy to do a live debug, but since this seems to involve an interaction between three packages, only one of which is org, and it’s quite easy to find an alternative way to achieve what I’m trying to do, I‘d probably suggest just ignoring this for now. > On May 25, 2022, at 9:27 PM, Ihor Radchenko wrote: > > Richard Stanton writes: > >> Odd. Invoking it as you do on my Mac, I get the same results I noted >> earlier. > > Then, can you ask some other Mac user to reproduce? It is hard to fix > something not reproducible on my system :( > > Or maybe we can arrange a live screensharing to directly debug the issue > on your system. > > Best, > Ihor
Re: About 'inline special blocks'
+1 Eric S Fraga writes: > On Tuesday, 24 May 2022 at 10:51, Timothy wrote: >> To me, this is another reason for comment and #+attr_X lines not to >> break paragraphs [...]. > > And, in fact, if this were true (which I would like), I personally would > see no reason for having inline special blocks. > > Just my 2¢.
Re: export regions of a org files to other formats (most likely only to a buffer).
Uwe Brauer writes: >> Could you please clarify which part of the function docstring was not >> clear? > > Well > | org-export-dispatch is an interactive compiled Lisp function in > | ‘ox.el’. > | > | (org-export-dispatch ARG) > ... > > Does not mention, that a selected region gets exported. Fair enough. Ironically, it is not even wrong. Looking at the source code, respecting region is merely a convention coming from most of backends calling `org-export-as'. As one possibility, we can add something like the following to the docstring: "Usually, exporting respects current narrowing and active region, though individual export backends might not follow the convention. See `org-export-as' for more details." Alternatively, we can modify `org-export-define-backend' to change the docstring with links to individual backend exporters. Or we may modify the dispatcher menu to indicate active region. Though it is not guaranteed to be obeyed by the backends. Best, Ihor
