[WIP] TeXpresso integration #2975
Conversation
|
First: I'm very happy to see such a contribution! And I look forward to reviewing the code. But I'm on vacation right now, and I can't promise that I'll be able to review this immediately. I'll look at it as soon as I get the time!
I was not aware of TeXpresso. It looks very interesting. It would be nice to hear more about how it works - how is it possible to be "so fast" wrt. compile times? Does it work well even for large and complex documents? |
|
Hi @tsung-ju & @lervag, I am glad to see this contribution. I don't have much free time these days, so I will only follow this from a distance.
I can explain a bit how TeXpresso works. The two main pieces are the engine, a fork of XeTeX, and the driver, which plays two roles: feeding the engine and rendering the output. Let's look at the engine first. It's a fork of XeTeX, currently the one found in the Tectonic distribution, but i would like to synchronize with TeXlive in the future. The main purpose of the fork is to redirect the I/O, so that the data can come from a custom source, e.g. an editor mode, and not necessarily from the file system. This is also used to keep track of the contents observed by the TeX process, in order to recompute things only when they change. The driver use this to (1) feed the engine with data coming either from the file system, a cache of the TeX packages (this directly comes from Tectonic at the moment) or the buffers of the editor, and (2) take snapshots from time to time by forking the engine (fork as in unix's The rendering pipeline is entirely custom and is built on top of the DVI/XDV format. Mupdf is not really used as a PDF renderer but rather as a framework for managing fonts and drawing to a canvas. The PDF renderer is used only to implement
I think it works well with large and complex documents, as long as they are XeTeX compatible. |
👍
Thanks for the info! Sounds like this may be a very interesting idea and a useful addition to VimTeX! |
| @@ -304,7 +304,7 @@ endfunction | |||
| let s:compiler_jobs = {} | |||
| function! s:compiler_jobs.exec(cmd) abort dict " {{{1 | |||
| let l:options = { | |||
| \ 'in_io': 'null', | |||
| \ 'in_io': 'pipe', | |||
There was a problem hiding this comment.
I'm curious, is it safe to use pipe here also for the existing engines?
|
|
||
| if has('nvim') | ||
| let s:nvim_attach = luaeval(' | ||
| \ function() |
There was a problem hiding this comment.
I think I would prefer to define the function in a .lua file under /lua/vimtex/.... It would make for a slightly cleaner code here and it becomes easier to lint and maintain the lua code. Further, I would also prefer to add type hints to the function.
| " }}}1 | ||
|
|
||
| function! s:compiler.__init() abort dict " {{{1 | ||
| let self.start = function('s:compiler_start', [self.start]) |
There was a problem hiding this comment.
I think it would look slightly cleaner to define the .start and .stop methods more "explicitly" with e.g. function! s:compiler.start(...) abort dict in line 66.
There was a problem hiding this comment.
Ah, sorry, I now noticed that this way allows to retain the "super" method. That's neat!
|
I've looked at the code and I think in general it seems very good. Thanks for following my conventions! I've not tested it myself yet. I look forward to testing it. One major thing that is missing for now is documentation. I think a nice starting point is to add something similar to the docs for |
TeXpresso (by @let-def) is a program that provides a "live rendering" experience when editing LaTeX documents. This PR aims to integrate TeXpresso into VimTeX as a compiler.
Unlike other latex compilers, TeXpresso combines a compiler based on tectonic and a pdf viewer based on MuPDF, and communicates file changes, quickfix items, and synctex through stdio. In this PR, these are implemented by opening a continuous compiler and changing the input mode to
'pipe'inautoload/vimtex/compiler/_template.vim.Most main features of TeXpresso including live editing, synctex, quickfix, theme color syncing are working. However, the code still have some rough edges (hence marked as draft). Please feel free to try the code out. Any suggestion would be really appreciated.