-
Notifications
You must be signed in to change notification settings - Fork 395
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
latexrun support #602
Comments
I looked at latexrun again and I don't think that it is a suitable alternative at the moment. For example, there seems to be no way to include a call to |
@languitar You are right, cf. aclements/latexrun#30. However, I am curious if it would not still be nice to add an alternative to latexmk as a compiler engine. Note, however, that this will require a major update. Today, the latexmk code is intertwined with a lot of the other code. I will have to find the correct "pattern" that should be refactored and create an abstract layer between vimtex and the compiler layer. I think this would be a nice addition, and I am planning to work on this when I get the time. @anntzer I'm sorry for not responding sooner. As written above, I think it makes sense to add this feature, but it requires a lot of work. I hope I might get time to work on it during winter/sprint 2017. I can't promise anything, though. |
No worries, thanks for looking into it! |
This issue is now covered by #651. |
latexrun (https://github.com/aclements/latexrun) is a nice alternative to latexmk that 1) nicely puts all auxiliary files in a separate directory but not the final pdf (basically similar to latexrun's -auxdir, see #220) and 2) filters away most of the irrelevant output of pdflatex (and friends) and colorizes the rest.
See https://github.com/aclements/latexrun#latexmk for a comparison.
The combination of these two features make latexrun very nice to use.
Any chance it could be supported by vimtex? Thanks!
The text was updated successfully, but these errors were encountered: