Skip to content
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

Make init_errorformat() global function #49

Closed
petobens opened this issue Aug 13, 2014 · 8 comments
Closed

Make init_errorformat() global function #49

petobens opened this issue Aug 13, 2014 · 8 comments

Comments

@petobens
Copy link

Is it possible to make the s:init_errorformat() a global function? I like to use vim-latex's error format in a script and in order to do so I have to either run latex#init() (which is a global function) or copy the s:init_errorformat() function to my script.

If this is not possible, if there is another way of calling the init_function from outside the script, or if this breaks some behavior just ignore this request and close the issue.
Thank you!

@petobens
Copy link
Author

On a related note (and since I read that in the past you looked into dispatch.vim) I wonder if you know how to achieve the following.

I have this function to run my latex files with dispatch.vim;

function! RunDispatch()
    let mainfile = g:latex#data[b:latex.id].tex
    let &l:makeprg = 'arara -v ' . mainfile
    execute 'Make'
endfunction

Once the build finishes I want to call latex#latexmk#errors(force) (because I want to use as a cfile the log file and not the output of arara in the console). Do you know how to call that function once, and only once, the build has finished? I read that

Dispatch fires a QuickFixCmdPost cgetfile event each time a build finishes

but I don't quite understand how to use that. Doing:

augroup ps_dispatch
    au!
    au QuickFixCmdPost cgetfile execute 'cgetfile '.fnameescape(g:latex#data[b:latex.id].log())
augroup END

seems to work if I stay in the tex file. But if I switch to another file (for instance to a .vim file) while the build is running then it fails (presumably because it doesn't know what g:latex#data[b:latex.id].log() means) .

@lervag
Copy link
Owner

lervag commented Aug 16, 2014

To your first comment: I am not really sure about this. Personally, I would like to keep the plugin as a relatively general latex plugin, although minimalistic and with a well documented API. I find the errorformat to be very intrinsic to the latex filetype, and so I don't really see the need to let the s:init_errorformat be accessible to the user. Since you do not want to call the latex#init() function, it seems you are sort of building your own system based on vim-latex. I am curious to why you do not want to initialize vim-latex; perhaps this issue could be solved by changing something else?

To your second comment: First, I notice that you must have called the init function, or else the g:latex#data should not have been initialized? Anyway. First: g:latex#data[b:latex.id] is only possible in a tex buffer, due to the b:latex.id. If you always only work on a single latex project in one vim instance, then you could use g:latex#data[0]. I think you could call ...#errors(force) with the autocommand as well, but it relies on the b:latex.id variable which is only available in a tex buffer. You could check out vim-quickrun. It seems to allow much more customization than vim-dispatch, but it is also more complicated. I didn't see exactly how, but I think you should be able to add hooks that are called after the compilation is finished.

@petobens
Copy link
Author

Thanks for your comment and sorry for my late reply.

I wanted to call init_errorformat() globally because I was trying to compile a latex project on the foreground and asynchronously using vimshell. It kind of works but dispatch is definitely better for asynchronous compilation (although I sacrifice output visibility since it compiles it in the background).

Thanks for suggesting vim-quickrun. I''ll have a look into it.

@lervag
Copy link
Owner

lervag commented Aug 22, 2014

Ok. I'm curious: Why do you not use latexmk? I can sort of understand that people prefer manual compilation, but this can still be achieved with latexmk. I am currently considering to modify vim-latex to fully support manual mode, but at the moment it should work if you do as explained in #50.

@petobens
Copy link
Author

Mmmm I never actually tried latexmk. In fact I thought that i) it didn't work well on Windows and ii) it only allowed continuous compilation. Apparently those two things aren't true.

The thing I like about arara (and the main reason why is use it) is that I can set, through comments in the source file, compilations routines that are specific to each document class.

Do you fully recommend latexmk? Maybe I should give it a try.

@lervag
Copy link
Owner

lervag commented Aug 23, 2014

I have not personally used arara, but I don't really see why I would want to. latexmk is very convenient, and after I started to use it, I have never looked back. I very much like the continuous mode, but I both understand and respect that others want to have somewhat more control over the compilation. latexmk works well in both cases.

Note that I do use a .latexmkrc file, but vim-latex should pass the most common/important options directly as well.

Btw, you may be interested in this discussion.

@lervag
Copy link
Owner

lervag commented Aug 24, 2014

@petobens Just FYI: I have now implemented options to disable continuous compilation with latexmk. This means you can set g:latex_latexmk_continuous=0 to get single shot compilations. If you prefer, you may also use g:latex_latexmk_background=1 to make the compilation run in the background.

@petobens
Copy link
Author

Thank you lervag for both of comments (I had completely missed the first one, I apologize for that).

The discussion at tex.stackexchange in indeed interesting. Given that and the fact that now it is possible to disable continuous compilation means that I will be trying latexmk in the next days.

Once again for such a great plugin and the excellent support you provide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants