From: Tim Cross <theophilusx@gmail.com>
To: Uwe Brauer <oub@mat.ucm.es>
Cc: emacs-orgmode@gnu.org
Subject: Re: cannot export to beamer.
Date: Mon, 17 Dec 2018 08:36:07 +1100 [thread overview]
Message-ID: <878t0pw3w8.fsf@gmail.com> (raw)
In-Reply-To: <87h8fdmbih.fsf@mat.ucm.es>
I suspect that the recent changes in how Emacs runs initialisation may
well expose a few edge cases for the customise interface. The custimise
interface is fairly basic and makes a few assumptions which may not hold
once you start altering the order of initialisation and package
loading. While it all works fine 80% of the time, it may fail for more
complex situations and the reality is, Org is large and complex.
Strictly speaking, I don't think it is a bug. The problem is getting the
right balance of what to load and what to leave for the user to decide
to load. If you never use beamer, then having all the beamer stuff
loaded by default is only going to slow down start up (though I do think
people are way too obsessed with startup time these days! I start emacs
about once per week and only that often because I shutdown my laptop on
the weekend when I leave work!). If beamer is not loaded when you
customise org-latex-classes, then it won't be in the variable and if it
isn't in the variable, it cannot be saved into the custom block. If you
then later decide to load it and it is loaded before your customisation
is loaded, then the value it adds to org-latex-classes is lost. If on
the other hand we 'hard code' it into the variable so it doesn't depend
on whether ox-beamer is loaded, then a definition will exist which won't
work when the user tries to use it as ox-beamer is not
loaded. Previously, I think custom blocks were loaded at the start of
your init, so before org was loaded, so this was less of an issue. No
with the early init stuff, things are not quite the same (a lot of guess
work here!).
Tim
Uwe Brauer <oub@mat.ucm.es> writes:
>>>> "Tim" == Tim Cross <theophilusx@gmail.com> writes:
>
> > Just a shot in the dark here .....
>
> > You mentioned you used custom to modify the org-latex-classes
> > variable. Does the code in the custom 'block' of your init file have
> > beamer as one of the classes?
>
> No it does not and this turns out a problem, also I thought the
> ox-beamer code contains a add-to-list which should do add beamer, but it
> seems not to do it.
>
>
> > My suspicion is that when you added your exam class, for some
> > reason, beamer had not been loaded and was not yet in the variable
> > definition. When you edited it to add your exam class it has saved
> > a version without beamer as a class.
>
> > When you start emacs, with the new init and run order, the code
>
> >> (unless (assoc "beamer" org-latex-classes)
> >> (add-to-list 'org-latex-classes
> >> '("beamer"
> >> "\\documentclass[presentation]{beamer}"
> >> ("\\section{%s}" . "\\section*{%s}")
> >> ("\\subsection{%s}" . "\\subsection*{%s}")
> >> ("\\subsubsection{%s}" . "\\subsubsection*{%s}"))))
>
> > is executed and beamer is added, but then your custom settings are
> > evaluated and the variable is reset with the version you added the exam
> > class to, which has no beamer entry, is used to reset the variable and
> > the beamer setting is lost.
>
>
> What you say makes send but this seems to defy the whole idea of custom!
>
>
> > I would start by deleting the org-latex-classes customization and try
> > adding it again to see if that fixes the problem. This is one reason I
> > rarely use customise - I prefer to have the code in my own init file so
> > that I can see exactly when everything is run.
>
> Thanks! I will do that and you are very right about custom, it is very
> convenient but buggier than I thought.
>
> Uwe
--
Tim Cross
next prev parent reply other threads:[~2018-12-16 21:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-15 17:38 cannot export to beamer Uwe Brauer
2018-12-15 17:49 ` Ken Mankoff
2018-12-15 17:54 ` Uwe Brauer
2018-12-17 14:20 ` Nick Dokos
2018-12-15 18:14 ` Josiah Schwab
2018-12-15 18:48 ` Colin Baxter
2018-12-15 19:30 ` Uwe Brauer
2018-12-15 20:43 ` Uwe Brauer
2018-12-16 10:25 ` Eric S Fraga
2018-12-16 18:16 ` Uwe Brauer
2018-12-16 19:21 ` Tim Cross
2018-12-16 21:01 ` Uwe Brauer
2018-12-16 21:36 ` Tim Cross [this message]
2018-12-16 19:46 ` Ken Mankoff
2018-12-16 21:11 ` Uwe Brauer
2018-12-16 22:37 ` Eric S Fraga
2018-12-17 8:02 ` Uwe Brauer
2018-12-17 9:53 ` Eric S Fraga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878t0pw3w8.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=oub@mat.ucm.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).