Re: [O] minimal testing setup for pdf export?
On 2019-08-27 at 03:20 +02, Matt Price wrote... > Can someone point me to a minimal setup for testing PDF export with "emacs > -Q"? I am unable to produce a pdf with default settings and I am pretty > sure that the latex is invalid... but I'm having trouble testing it since > I 9still) know so little about latex. I blank file is an MWE. It is highly unlikely Org is producing something invalid here. I'd look at operator error :) What version of Emacs? What version of Org? -k.
[O] minimal testing setup for pdf export?
Can someone point me to a minimal setup for testing PDF export with "emacs -Q"? I am unable to produce a pdf with default settings and I am pretty sure that the latex is invalid... but I'm having trouble testing it since I 9still) know so little about latex. Thanks everyone! Matt
Re: [O] org-drill extremely slow with Org 9.2.5
> "OK" == Oleh Krehel writes: OK> I noticed org-drill being slow three years ago when I tried to OK> learn it. So I wrote my own package: OK> https://github.com/abo-abo/pamparam/. It's quite fast: it takes OK> 0.6s to sync my 3300 cards from the master Org file. And OK> day-to-day learning operations like building a schedule or OK> fetching a card are instantaneous. The master file is OK> relatively small, since it stores no metadata: less than 1 OK> lines. The metadata is stored per-card, each card is in its own OK> file. The whole thing is backed by Git. All your learning OK> sessions are stored in commits as well. OK> Check it out. It might have less features, but it's really fast OK> and has served me well. Hi Oleh, pamparam looks interesting, however the very first blocker of adoption is that having to type the answers is slower than anything else... And not always feasible. Nevertheless the concepts behind pamparam are interesting. When I grep all the :PROPERTIES: out of my org-drill file, Org can visit and navigate the resulting file completely fine. So the problem is how Org deals with its properties. I can see two options: a) to fix Org property processing b) to change org-drill to off-load metadata to a separate file I'm afraid b) alone wouldn't help, since when I retain just :ID: properties, then the file is unusably slow in Org.
Re: [O] [bug] Export to latex truncates long subsections (WE attached)
Hi Vladimir, I see two problems in the generated LaTeX-file you'd need to address. First, LaTeX has problems handling URLs in section (or subsection) headers. That's one of the reasons LaTeX chokes on the second run of that file -- it's only partially generated, not completely. The second is the fact that there's no content in all those subsections. I guess that's why LaTeX's page break algorithm fails: It does not want to make a page break immediately after a section heading. Thus there's no viable place for LaTeX to break that page. As there's no contents in all those subsections, how about changing it to a list with checkboxes? Then the problem with the URLs is solved too. HTH, Julius Am 26.08.19 um 05:46 schrieb Vladimir Nikishkin: > I have a problem in that when I try to export an .org file into > latex/pdf, long sections are not wrapped to the next page, but are > truncated instead.
Re: [O] [bug] Export to latex truncates long subsections (WE attached)
Hello,
Vladimir Nikishkin writes:
> I have a problem in that when I try to export an .org file into latex/pdf,
> long sections are not wrapped to the next page, but are truncated instead.
>
> The result is on the picture (points 10.34 to 10.37 missing), and the
> (not)working example is attached to this email.
The LaTeX code generated by Org looks correct.
I tried to remove all \label{...}, all \href{...} from the ".tex" file,
but the problem is still the same.
It may be a LaTeX issue, not an Org one. You may want to investigate in
this direction.
HTH,
Regards,
--
Nicolas Goaziou
