Ihor Radchenko writes:
> Yet, the information is surprisingly scattered. I was unable to find a
> single guide on the available possibilities. Mostly unanswered or
> partially answered questions from users.
Yes you're right. In addition, what I have been testing is not a panacea
either. In
Juan Manuel Macías writes:
> Improving performance and compile time in TeX is an old topic, and there
> are a few tricks here and there. But TeX is what Emacs is, both are
> venerably old; and both are single-thread.
Yet, the information is surprisingly scattered. I was unable to find a
single
Ihor Radchenko writes:
> A more advanced approach would be using
> \include + \includeonly instead of \input:
>
> https://web.archive.org/web/20160627050806/http://www.howtotex.com/tips-tricks/faster-latex-part-i-compile-only-parts/
Yeah, \include and \includeonly save the .aux files for each
Juan Manuel Macías writes:
> Ihor Radchenko writes:
>
>> 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?
>
> The -pvc flag means that if latexmk detects
Ihor Radchenko writes:
> 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?
The -pvc flag means that if latexmk detects any modification to any
document
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
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
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
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
>>
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
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.
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
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
13 matches
Mail list logo