Editors like BaKoMa TeX and texpad seem to be able to recompile individual pages. I'm interested in how to makes this happen myself, but have been unable to find out how to do this.

I'm hoping that someone more knowledgeable might be able to provide some answers here, what I'm ideally looking for is a step by step process, ideally the sort that could be integrated into an editor (I assist with the development of the LaTeX Workshop VSCode extension).

  • What exactly is your question here? Are you looking for a way to replicate this behavior with the standard TeX implementations? Or are you asking how this behavior could be implemented in general in a new TeX compiler? IMHO, it's impossible to have single-page compilation with the compilers based on Knuth's TeX implementation, as a tiny change on any page can cause a cascade of effects on all the following pages. So it's impossible to get (even almost) correct output for any page after that change without processing the page that causes it.
    – siracusa
    Aug 17 '19 at 3:24
  • I'm looking, ideally, for a way this can replicated with standard TeX implementations. I'm aware that the state of a given page depends on the preceding content. I have previously seen mention of functionality that 'dumps' the state of the TeX compiler at a certain point, which may be something of use.
    – tecosaur
    Aug 17 '19 at 3:42
  • The question can be reworded at: These editors do recompilation of an individual page, somehow. I'm assuming they haven't written their own compiler. How do they do it? (prefably answered in such a way that would help with me producing the same effect). Hope that helps with clarity.
    – tecosaur
    Aug 17 '19 at 3:45
  • @tecosaur Of course both BaKoMa TeX and Texpad have modified the TeX program (what you're calling the “compiler”), and they've even documented/mentioned this. It's not something you can do with a standard TeX implementation as in TeX Live or MikTeX. Why do you assume so? And what answer is possible for the question given the incorrect assumption? Aug 17 '19 at 4:09
  • Ah. I assumed that BaKoMa TeX and Texpad were using a standard TeX program in clever ways. If this assumption is incorrect, then I can only apologise for my mistake and mark this question as "invalid" or the like. What I would be interested in then, is the closest one can get using a default TeX Compiler.
    – tecosaur
    Aug 17 '19 at 4:34

AucTeX, Emacs most famous major-mode for *TeX has a TeX-command-region function, that will run a compiler on whatever part of the file previously selected with the mouse (of course you can do it with the keyboard too). You can easily check this function code within Emacs if you want to implement it.

As I am no longer an Emacs user, I just run my not-so-elegant-but-working external shell script. Should work with any texlive installation and ksh, maybe any other shell. This should certainly not be implemented in any editor.

#tex_region.sh first_line last_line file [master file]

#where am I?
#is there a master file?
if [[ -s $4 ]];
#copy the preamble
sed -e '/maketitle/,$d' $maitre > /tmp/$maitre ;
#copy file from line $2 to line $3
head -n $2 $3 |tail -n $(( $2 - $1 + 1 )) |\
#absolute path to graphic files
sed "/includegraphics/s:{\([^}]\+}\):{$ousuisje/\1:">> /tmp/$maitre
#add \end{document} to temporary file
echo -E "\end{document}" >> /tmp/$maitre

#goes to /tmp
cd /tmp

#checks which *latex has to be called then compile
laoulualatex=$(grep -c '^\\\usepackage{polyglossia}' $maitre)
if (( $laoulualatex == 1 )) ;
   # if your distro is texlive, binaries should be in $TEXDIR/bin
   lualatex $maitre ;
   pdflatex $maitre ;

######read the pdf with mupdf (code inspired by Vincent Lozano's framabook
###### "pour aller plus loin avec la ligne de commande")
#checks whether the pdf is opened with mupdf
pidpdf=$(ps -U dthiriet | grep mupdf | grep ${maitre%tex}pdf | cut -d' ' -f1)
if test -z $pidpdf ;
   #if not, calls mupdf
   mupdf ${maitre%tex}pdf & 
   #send a SIGHUP signal to mupdf to actualize the pdf
   kill -s HUP $pidpdf ;
fi ;

#####back to my file
cd $ousuisje

PS it is better to call programs with their absolute path in a script, but I deleted them when copying my script to make this script a bit more portable.


Just to make sure: You know about having a main document and including as many parts as you wish using \include, \input, \includeonly, for details see here: When should I use \input vs. \include? . This makes recompilation rather fast.

You can even speed up compilation by using a precompiled format, see the package mylatexformat.

And you can boost that if you let latexmk compile in the background.

Maybe your editor allows an automatic saving, e.g. two seconds after you stopped typing. latexmk notices the saving and starts compiling with the precompiled format.

In the end you get an almost instantenous picture of the page where you have changed something.

  • Thanks for the reply, but I think you misunderstand the question. This is not so much about user tricks for making compilation faster/easier, I'm looking for a method that may be called from an editor to compile an individual page (I assist with the development of the LaTeX Workshop VSCode extension).
    – tecosaur
    Aug 20 '19 at 15:50
  • @tecosaur What a pity. However, who needs to compile single pages as long as compilation of more text is fast enough?
    – Keks Dose
    Aug 20 '19 at 16:07

To get to a real online compilation other software such as BaKoMa TeX use a modified (La-)TeX. With the newer LuaTeX it is easier to hook deep into the internals, maybe this is a route that you can investigate.

As a workaround what can be done though is to start the compilation with LaTeX up to the point of the current cursor position in your editor. Let's say your complete document looks as follows:



[cursor position]

Some more example text.

Instead of continuing, end input here and abort the compilation, the DVI file will still get written up to this point.



It is possible to input and compile the first block with LaTeX. Then when the user takes a short break the compilation can continue and can be aborted for example at the next page. The DVI document is then almost immediately available. In the background you can then start the compilation process up to the point of the cursor again so that it does not interrupt user workflow.

With a modified LaTeX executable the first optimization would be recording the compilation process in a kind of cache, so that the part before the current page does not need to be compiled again ever unless it changes. That makes this approach also somewhat feasible, there is no programmatic way to influence the content of a previous page with code on the later pages. This sets a LaTeX file apart from e.g. a C source file where at the end of the file previous parts can be changed.

  • Thanks for this. It looks like the answer once again goes back to a modified executable.
    – tecosaur
    Aug 20 '19 at 15:52
  • To some extend. I would not say the first approach is not feasible. Markdown editors have similar issues, of course the caching would help a lot. I don't know if something like that might be even be possible within LuaLaTeX already.
    – Alexander
    Aug 23 '19 at 10:25
  • Could the downvoter explain what is wrong with my answer?
    – Alexander
    Oct 15 '19 at 11:16

My answer may be very late. You can put % and enclose all that need not be compiled in a curly bracket. This will not be compiled

  • Not really what I'm looking for I'm afraid.
    – tecosaur
    Nov 10 '19 at 16:03

I know this is not exactly what you are looking for, but there are plugins for VIM that provide a live preview of the document.

With vim-latex-live-preview you can obtain that effect. Of course, this will only work while using VIM as your editor. I'm not an EMACS user, but I'm sure there are similar capabilities there too.

I hope this can guide you in the right direction.

  • 1
    The live previewer doesn't provide partial compilation, it just uses the standard compilers to build the whole document on every change in the input document.
    – siracusa
    Aug 20 '19 at 3:17
  • 1
    ^ @Salatiel Garcia thanks for trying but I'm afraid that's not what I'm looking for
    – tecosaur
    Aug 20 '19 at 3:20
  • Add that which you do not wantt to be compiled betwee% { }. This will omit that portion. This worked well for me. Nov 11 '19 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.