Re: Org LaTeX Beamer export and the order of loading packages and theme (XeLaTeX and fonts)

[Lennart C. Karssen]

Dear Igor,

Thanks for your reply.

On 09-01-2024 22:15, Ihor Radchenko wrote:

"Lennart C. Karssen"  writes:


1) Is there a way to tell Org to export the #+BEAMER_THEME lines before
anything else?


Yes. You can customize "beamer" class in `org-latex-classes' or define a
custom (for example, "my-beamer") class and add #+LATEX_CLASS: my-beamer
to the Org file.


Ah, indeed, I hadn't thought of that taking route. I will give it a try.



This will give you full control over the preamble layout.


2) Is there a reason why the Beamer theme options are exported after
other LaTeX packages? Wouldn't it be better to export the Beamer theme
options before loading additional packages? The reason for that being
that the theme sets defaults, which can then (potentially) be altered by
loading additional packages.


No specific reason that I am aware of.
Your suggestion sounds reasonable, but I'd like to hear from our LaTeX
experts first ;)


Of course. Let's see what they have to say.


Lennart.

--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands

lenn...@karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-


OpenPGP_signature.asc
Description: OpenPGP digital signature

Org LaTeX Beamer export and the order of loading packages and theme (XeLaTeX and fonts)

[Lennart C. Karssen]

Dear list,

I have been happily using the LaTeX Beamer export for several years. 
Recently, I had to update one of the themes I use for the slides and ran 
into a problem related to the order in which the theme and the LaTeX 
packages are exported to the .tex file.


I use XeLaTeX to compile my documents so I can use fonts like Fira Sans 
in my slides. For this, I load the fontspec package in my Beamer theme 
font file. The Org export code puts the #+BEAMER_THEME options after the 
packages loaded org-latex-packages-alist (and those specified on 
#+LATEX_HEADER lines) in the LaTeX preamble. In my case this gives a 
font problem, because my org-latex-packages-alist loads the polyglossia 
package (which loads the fontspec package needed for the fonts), but my 
beamer theme also tries to load fontspec and somehow (probably related 
to options passed to fontspec), this leads to different (unwanted) 
behaviour.


The desired behaviour would be to have sans-serif math in my equations, 
which works fine if I load my theme before loading other packages (in 
pure LaTeX). However, in the case of Org export, the \usetheme{} 
commands ends up after the \usepackage lines, which leads to serif fonts 
in my equations.


So my questions are basically the following:

1) Is there a way to tell Org to export the #+BEAMER_THEME lines before 
anything else?


2) Is there a reason why the Beamer theme options are exported after 
other LaTeX packages? Wouldn't it be better to export the Beamer theme 
options before loading additional packages? The reason for that being 
that the theme sets defaults, which can then (potentially) be altered by 
loading additional packages.



Best regards,

Lennart Karssen.
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands

lenn...@karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Fwd: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

[Lennart C. Karssen]

Dear list,

Confirmed.

This is to confirm Micheal's overservation that
`org-save-all-org-buffers' doesn't save any Org buffers any more in
Emacs 28, compiled a few days ago from commit d86b2e59c and Org 9.5 from
Elpa, running on Ubuntu Linux 21.04.
I can't say if this is because of the upgrade of Org 9.5 or the newly
compiled Emacs as I did both at the same time.
Command used for testing:
  emacs -Q -L ~/.emacs.d/elpa/org-9.5/ /tmp/test.org


Best regards,

Lennart Karssen.

On 05-10-2021 21:51, Michael Powe wrote:
> 
> forgot to hit 'reply all.'
> 
> 
>  Forwarded Message 
> Subject:  Re: [BUG] org-save-all-org-buffers reapplies startup
> visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]
> Date: Tue, 5 Oct 2021 15:47:42 -0400
> From: Michael Powe 
> To:   Bhavin Gandhi 
> 
> 
> 
> Hello,
> 
> I hesitate to reply, but here's a report from Windows 10.
> 
> works as expected
> C:\Emacs\emacs-28\bin\runemacs.exe -Q -L
> C:\Users\micha\AppData\Roaming\.emacs.d\elpa\org-9.5\ 'G:\My
> Drive\org\daily.org'
> GNU Emacs 28.0.50 (build 1, x86_64-w64-mingw32) of 2021-08-11
> Org mode version 9.5 (9.5-g0a86ad @
> c:/Users/micha/AppData/Roaming/.emacs.d/elpa/org-9.5/)
> 
> Now for the bad news.
> 
> does not save files at all!
> C:\Emacs\emacs29\bin\runemacs.exe -Q 'G:\My Drive\org\daily.org'
> GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32) of 2021-10-02
> Org mode version 9.5 (release_9.5 @
> c:/Emacs/emacs29/share/emacs/29.0.50/lisp/org/)
> 
> Upon invoking the save, contents of the file shift to the left, then
> shift back; and that's it.
> 
> HTH.
> 
> mp
> 
> Bhavin Gandhi wrote on 10/5/2021 13:53:
>> Hello Marcel,
>>
>> On Tue, 5 Oct 2021 at 19:14, Marcel van der Boom  wrote:
>>> […]
>>> - emacs -Q test.org
>>> - make sure the outline is unfolded
>>> - make a change so test.org is 'dirty'
>>> - M-x org-save-all-org-buffers
>>>
>>> Observed behaviour:
>>> The outline in test.org will collapse and only show 'Header one'
>>>
>>> Expected behaviour:
>>> Outline state does not change on calling `org-save-all-buffers`
>>>
>> I tried to follow the above steps with Emacs 27.1, and Org mode latest
>> main branch as well as the release_9.5 tag. The only different step I
>> took was this:
>>
>> emacs -Q -L ~/src/org-mode/lisp/ ~/test.org
>>
>> When I modify the test.org and call org-save-all-org-buffers, all the
>> headings remain unfolded. I tried to switch to a different buffer and
>> called the function, but still it remained in overview state. Maybe
>> someone with the latest Emacs build from master can try to reproduce?
>>
> 
> -- 
> Sent from Postbox 

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands

lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-



OpenPGP_signature
Description: OpenPGP digital signature

Re: Global variables in Org mode document with source blocks

[Lennart C. Karssen]

Hi Greg,

On 18-05-2021 19:25, Greg Minshall wrote:
> Lennart,
> 
> John's idea seems good.  also, you could generate a separate RESULT for
> each language, then :var each language's "failed" RESULT into your bash
> block and fail if any of them are set?

The main problem I see with that solution is that my code blocks print
raw Org code/text, e.g. tables of results or a paragraph of text that
depends on the computations done in the code blocks. I haven't tried,
but passing and parsing those multiline RESULT blocks into a final
'conclusion' block is probably not very easy.

I ended up going for a slightly adapted version of John's first idea:
Adding a # failure-CODE line to any block that fails. That line is
ignored on export to PDF, but can still be counted in a final code block
that searches the buffer for matching regexps.


Thanks for your input.

Lennart.

> 
> cheers, Greg
> 

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands

lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-



OpenPGP_signature
Description: OpenPGP digital signature

Re: Global variables in Org mode document with source blocks

[Lennart C. Karssen]

Dear John,

Thanks a lot for your quick reply. My apologies for not replying
earlier. Some urgent things came up that took my time.

I tried your suggestions and settled on a small adaptation of your first
suggestion. Because the output of my source blocks is raw Org code (i.e.
the report text that explains the failure), I can't directly print
=failure-DIGITS= or something similar. My solution to that is to append
=# failure-BLOCK= to the output text (which is ignored during export)
and use your =count-matches= suggestion to count those. The text =BLOCK=
is different for each code block and should allow me to specify which
blocks fail in the Conclusion section.


Thanks a lot!

Best regards,

Lennart.

On 18-05-2021 17:03, John Kitchin wrote:
> Given all the different languages involved, I don't think there is a way
> to use a common variable. 
> 
> One way might be to have each block output some kind of string if it
> fails, and then in the last block you could search for the buffer for
> that string. Something like this:
> 
> 
> * Section 1
> 
> #+BEGIN_SRC sh
> false || echo "failed"-`date +'%s'`
> #+END_SRC
> 
> #+RESULTS:
> : failed-1621348872
> 
> 
> #+BEGIN_SRC python
> import time
> 
> if not False:
>     print(f'failed-{time.time()}')
> #+END_SRC
> 
> #+RESULTS:
> : failed-1621348926.125608
> 
> 
> * Final section
> 
> #+BEGIN_SRC emacs-lisp
> (format "There were %s failed blocks" (count-matches "failed-[0-9]"
> (point-min) (point-max)))
> #+END_SRC
> 
> #+RESULTS:
> : There were 2 failed blocks
> 
> Some alternatives include writing/appending to a file on error, and then
> counting the number of lines.
> 
> Another route is to use a :post header and search for the string there.
> 
> #+BEGIN_SRC emacs-lisp
> (setq n-failures 0)
> #+END_SRC
> 
> #+RESULTS:
> : 0
> 
> #+name: fail-capture
> #+BEGIN_SRC emacs-lisp :var data=""
> (when (string-match "failed-[0-9]" data)
>   (incf n-failures)
>   (message "captured a failure in %s. n-failures=%s" data n-failures))
> #+END_SRC
> 
> #+BEGIN_SRC sh :post fail-capture(*this*)
> false || echo "failed"-`date +'%s'`
> #+END_SRC
> 
> #+RESULTS:
> : captured a failure in failed-1621349398. n-failures=1
> 
> 
> #+BEGIN_SRC python :post fail-capture(*this*)
> print('This did not fail')
> #+END_SRC
> 
> #+RESULTS:
> : nil
> 
> #+BEGIN_SRC python :post fail-capture(*this*)
> print('This failed-9')
> #+END_SRC
> 
> #+RESULTS:
> : captured a failure in This failed-9
> : . n-failures=2
> 
> All these approaches need you to handle and catch the errors. I think
> other kinds of errors would stop the export process. e.g. if a block
> errors out from division by zero or something.
> 
> I don't know how easy it would be to check if a src block succeeded or
> not. If it was easy, you might use the org-babel-after-execute-hook
> variable to update something when a failure is detected. Some blocks
> create an *Org-Babel Error Output buffer somewhere, but i don't know if
> this is 100% reliable across all blocks.
> 
> John
> 
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu <http://kitchingroup.cheme.cmu.edu>
> 
> 
> 
> On Tue, May 18, 2021 at 9:58 AM Lennart C. Karssen  <mailto:lenn...@karssen.org>> wrote:
> 
> Dear list,
> 
> I am working on a dynamic report in Org mode, where I use source blocks
> in various languages to process data. Several blocks produce text or
> tables that become part of the PDF on export.
> 
> The final chapter should state whether all checks passed, or whether one
> or more failed (it is not necessary to know which step failed).
> 
> In a single language environment, I would use a variable (called e.g.
> nrChecksFailed) that would be incremented for each failing check. In a
> single language Org document this could probably be done with a
> :session, but given that I mix Awk, Bash, Emacs lisp and R that doesn't
> look like the way to go. Do Org documents/source blocks have some
> concept of a (global) variable that I can pass to my SRC blocks and
> increment inside them?
> 
> E.g. after somehow initialising nrChecksFailed = 0, I would like to do:
> 
> #+header :var nFailed=nrChecksFailed :var someData=someData
> #+begin_src R :results raw
> do_some_check_here_on_someData
> 
> if (check_results_

Global variables in Org mode document with source blocks

[Lennart C. Karssen]

Dear list,

I am working on a dynamic report in Org mode, where I use source blocks
in various languages to process data. Several blocks produce text or
tables that become part of the PDF on export.

The final chapter should state whether all checks passed, or whether one
or more failed (it is not necessary to know which step failed).

In a single language environment, I would use a variable (called e.g.
nrChecksFailed) that would be incremented for each failing check. In a
single language Org document this could probably be done with a
:session, but given that I mix Awk, Bash, Emacs lisp and R that doesn't
look like the way to go. Do Org documents/source blocks have some
concept of a (global) variable that I can pass to my SRC blocks and
increment inside them?

E.g. after somehow initialising nrChecksFailed = 0, I would like to do:

#+header :var nFailed=nrChecksFailed :var someData=someData
#+begin_src R :results raw
do_some_check_here_on_someData

if (check_results_OK) {
  cat("check A passed\n")
} else {
  cat("check A *failed*\n")
  nFailed <- nFailed + 1
}
#+end_src

So that in my conclusion chapter I can do for example:

#+header: :var nFailed=nrChecksFailed
#+begin_src bash  :results raw
if [[ nFailed -eq 0 ]]; then
  echo "All checks passed
else
 echo "One or more checks *failed!*"
fi
#+end_src


Best regards,

Lennart.

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
The Netherlands

lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-



OpenPGP_signature
Description: OpenPGP digital signature

Re: Release Org 9.4.2

[Lennart C. Karssen]

On 16-12-2020 19:41, Tim Cross wrote:
> 
> 
> Github is not an option here. The problem is, github encourages the use
> of proprietary, non-free software, which conflicts with the GNU's
> primary goal of software freedom. As Org mode is a GNU project, it
> cannot use Github in any fashion which would encourage the use of github
> interfaces that require/encourage the use of non-free software, which
> unfortunately, key parts of their web UI does.

I'm not an expert in web technologies and their licenses, but given that
Debian, KDE and Gnome use Gitlab [1,2] this Github alternative may be an
option to consider too. The open core of Gitlab is licensed under the
MIT license [1] (which may or may not be acceptable for this community...).

I personally use Gitlab both via the web interface and in Emacs via
Magit's forge [4]. So far, this works well for my daily workflow. I
guess the 'young ones' using Github would be equally happy with Gitlab.


My two cents,

Lennart.

[1] https://about.gitlab.com/solutions/open-source/
[2] https://salsa.debian.org/public
[4] https://github.com/magit/forge

> 
> With respect to providing a different forum which might e more familiar
> or more comfortable to younger users who are not as comfortable with a
> mailing list, I don't know what the answer is. By definition, being an
> old user who is out of step with the trends of the young, I an other old
> timers probably don't have the necessary familiarity with modern trends
> to do anything here. If young users need/want a different forum, they
> need to take on the responsibility for that initiative. The only
> restriction is that the forum must fit with the philosophy and guidelines
> of the FSF with respect to free (libre) software and not just 'open
> source'.
> 
> Personally, I think on-line communities went backwards after the decline
> of USERNET newsgroups.
> --
> Tim Cross
> 

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands

lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-



signature.asc
Description: OpenPGP digital signature

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Lennart C. Karssen]

Hi all,

On 01-10-2020 05:40, TEC wrote:
> 
> Bastien  writes:
> 
>> If there is absolutely zero burden put on the shoulders of Org's
>> maintainers, then I'm all for it.
> 
> From the look of things, there's just effort in the initial creation.
> 
>>> I think it would serve well the proliferation and
>>> popularization of org-mode.
>>
>> Agreed.
> 
> This is the main reason why I'm a fan of the idea :)
> 
>> Is anyone willing to check that there are no constraints?
> 
> I've read through https://tools.ietf.org/html/rfc6838 and I couldn't see
> any constraints placed on us beyond the initial registration's
> requirements.
> 
> For that, I think a formal syntax specification would be needed. Perhaps
> https://orgmode.org/worg/dev/org-syntax.html will do? It looks complete.


One of the things I have been wondering about with regard to Org syntax
is the use of capital letters vs. lowercase ones for e.g. blocks and
options.

The org-syntax.html document linked above lists blocks as
#+BEGIN_NAME/#+END_NAME, #+KEY: VALUE, #+CALL: VALUE, #+ATTR_BACKEND,
etc. all in uppercase.

On the other hand, the manual states in the introduction: "Keywords and
blocks are written in uppercase to enhance their readability, but you
can use lowercase in your Org files."

At the same time, when I run org-export-dispatch to insert the default
export template (via C-c C-e # default on Org 9.3) I get all #+options,
#+title, etc. lines in lowercase.


Wouldn't it be a good idea to standardise on either uppercase or
lowercase? Limitting the standard to only one of the two case options
will probably spark a huge debate on which one to choose because one
side would have to change their behaviour. But at least for the Org code
that is generated automatically like in the above case of the default
export template I think choosing a 'preferred' option that is consistent
with the syntax document and the manual would help.


Best regards,

Lennart.

> 
> I'm hoping we could then use https://tools.ietf.org/html/rfc7763
> (registration of text/markdown) as a template, where we could just link
> to the syntax specification.
> 
> Perhaps it could be worth putting the syntax spec under the main site as
> something like orgmode.org/syntax-spec.html.
> 
> I've also been considering spinning off the manual into a bit of a
> specification document (e.g. less of a guide / how-to, stripped down to
> just the bare information), so perhaps
> orgmode.org/specification.html#syntax ? I'd really like some second
> opinions.
> 
>> Is anyone willing to move forward with this registration?
> 
> In about two months, I am.
> 
> It looks like creating and draft and then emailing it to
> media-ty...@iana.org would probably be the best approach.
> 
> All the best,
> 
> Timothy.
> 

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
The Netherlands

lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-



signature.asc
Description: OpenPGP digital signature