Added custom callback for compile_command

[LeszekSwirski]

Adds an optional callback parameter to dispatch#compile_command. If this parameter is not present, it defaults to the old behaviour (calling s:cgetfile if this was a foreground request), but this allows library users to add custom behaviour (e.g. show quickfix after background requests are done, open the location list rather than the quickfix list).

This should make vim-dispatch more flexible for use by other plugins (see #47, LaTeX-Box#106 or synctastic#699), but doesn't break current APIs.

[LeszekSwirski]

Is there any particular reason why this PR got ignored? As far as I can see, it's well within the "spirit" of vim-dispatch.

[tpope]

It's been sitting in my rather daunting backlog. My concern is that background jobs don't fire a finish event on all adapters (particularly screen and tmux), so we'd be exposing an unreliable API.

[LeszekSwirski]

Can't argue with a backlog!

That's a fair concern, this sort of async emulation is a pretty leaky abstraction, and will probably always be unless vim itself is patched. I'd argue though that an unreliable API is better than no API at all, especially given how many other projects implement their own half-working callback functionality, which is equally unreliable, if not more. It'd be nice to at least have a standard as-good-as-we-can-get async-with-callback API -- and if vim ever gets an async patch, you can just transparently add it as an adapter and other plugins would benefit.

As an aside, this should work with tmux, since it patches the dispatch#complete functionality.

[tpope]

It will only work on tmux if has("gui_running") is true. That's a possibility in a Linux terminal but not in a Mac terminal.

[LeszekSwirski]

Don't you mean has("gui_running") is false? The autocmd is:

autocmd VimResized * if !has('gui_running') | call dispatch#tmux#poll() | endif

I might be misunderstanding the code of course.

[tpope]

If the gui is not running, that piece of code fires, and that piece of code is contingent on a resize event. Foreground tasks kick off a resize event on termination because they run in a split pane, but background tasks don't, because they run in a different tmux window.

[LeszekSwirski]

Ok, I'm still not clear on why this means that there's a difference between Linux and Mac, but it doesn't matter. My point (unreliable callback > no callback) still stands. Perhaps a dispatch#callback_available predicate would patch over the leakiness of the abstraction?

[tpope]

And that's where we disagree, as I feel broken is worse than nothing at all. But I'm willing to experiment after cutting a release next week. Can you start by clarifying how precisely you see LaTeX-Box working with dispatch.vim in the mix? In particular, why are you turning your nose up at a foreground dispatch?

[lervag]

For me this is no longer an issue, since I use my own for of LaTeX-Box (vim-latex), which uses background and continuous compilation with latexmk -pvc. latexmk has builtin callback functionality, which can use the vim server capability to give me callbacks after compilation of LaTeX documents.

If I were to use vim-dispatch for my own plugin (or for LaTeX-Box), then I could use any general method to compile my LaTeX document, including Makefiles, latexmk or manual use of pdflatex|latex|pdftex|bibtex|.... The reason I would NOT want a foreground dispatch is that LaTeX documents may take some time to compile. For big documents, the time may reach a minute or more. A foreground dispatch would then block editing for way too long.

[tpope]

"Foreground" dispatch only blocks for adapters where a reliable callback isn't available (i.e., there's no vim server, and we can't use the tmux resize trick.)

[lervag]

Then I am probably doing it wrong. I tested now with a very simple makefile. When I use Make, my buffer is replaced with an output buffer for the make process. Same holds if I set b:dispatch = 'latexmk' and use Dispatch. I tried with gvim and server. If I use Dispatch! or Make!, I get a headless background compilation with no callback.

[tpope]

If you're on Linux, in the gui, without an associated screen or tmux session, then yeah, there's no supported foreground dispatch configuration. But if you don't care about seeing the output, I think just rolling your own headless stuff as you've done is probably the way to go.

[tpope]

And that does highlight the actual problem: you'd rather sacrifice output visibility than asynchronicity in that particular setup. Which doesn't really conflict with any of my goals.

[lervag]

Yes, I'm on Linux and use the gui vim with no associated screen or tmux session. And yes, you are right with identifying the problem: I don't care about output visibility, but asynchronicity is important. In any case, my own headless approach works very well IMHO. So for me, this case is closed.

However, I realize that vim-dispatch may be very useful for some other projects. I really like the coupling with tmux!

[LeszekSwirski]

I have the same arguments as @lervag, that compilation takes time and that I'd be willing to sacrifice callback visibility for asynchronicity -- or more precisely, that in my use case I can get since I have vim-server compiled in, but the only way to have asynchronicity is to use background calls.

Really, I suppose that you see foreground/background as visible/invisible, while I see it as potentially synchronous/certainly asynchronous, which is contributing to our fundamental disagreement. In some ways, for me the asynchronicity of foreground calls is also an unreliable API.

Going back to the point in hand, I feel that exposing whether callbacks are available (providing the aforementioned dispatch#callback_available predicate and/or giving the user a warning if they specify a callback when they aren't available) is sufficient to move this from a "unreliable" API to a "known-limitations" API, which in my books is fine. If you disagree, well, that's probably an irreconcilable difference in philosophy and it's your library after all, so I won't argue.

Really, at this point I'm just waiting for neovim to come out with real async support, so that all of this stuff stops being a problem entirely.