Add a headless strategy with callback

[shym]

In all the possible stategies implemented already in vim-dispatch, I think is missing a combination I’d probably prefer in most cases, namely a mix of headless/Make! (no window show what’s going on) and tmux/Make (the quickfix window opens right when the task finished). A reason for this combination is the fact that I often want to run things that are so short, that the end result is just that my screen flashes when I Make (in tmux or x11 strategies).

(I imagine this could be headless/Make, when servername is set; or that would break something?)

[shym]

Thinking about it, that might be breaking the expected behaviour. If I try to sum up Make and Make! and their properties:

Property	Make	Make!	?
QF callback	must	must not	must
visible	must	may	may
async	should	must	should

Where visible is the fact that the user can see and interact with the build.

? is the policy I'm thinking of: it changes the trade-off by favouring asynchronicity over visibility. This policy would be better to develop other plugins (such as an asynchronous syntastic). By the way, thinking of that use-case, "visible" might be better as "rather not".

Proposal:

• expose a generic function (as a base for Make and Make! and for other plugins to use) that would take as argument a list of adapter functions and whether to open QF window,
• split up adapters that behave differently between foreground and background requests into two adapter functions,
• have adapters always trigger some callback whenever possible (I would love to have an indicator in my status bar showing whether a background job finished already or not, even if I don’t want to get the QF window open automatically),
• use two variables, g:dispatch_handlers_Make (starting with tmux_split, etc.) and g:dispatch_handlers_MakeBang (starting with tmux_window, etc.) to configure the behaviours of Make and Make!.

[tpope]

A lot to unpack here, but let's start here: why does "things that are so short" make you reach for asynchronous? When things are very short I prefer to just watch the whole thing unfold inline, because it doesn't have time to actually block me.

BTW #193 is probably going to change all of this.

[shym]

Indeed, #193 is probably the solution. The use-case I had in mind involved running a compiler that usually finishes almost immediately but sometimes takes some (up to a few minutes) to complete.

[Cimbali]

I'ù actually looking for an invisible-headless + callback too.

I'd argue instead of adding a new strategy, it's probably a better idea to change the current headless Make. It is not very useful as it just does the same as make, steals focus, and is completely synchronous.

Having it be invisible and open QF asynchronously makes more sense to me.

[shym]

Personally, since I usually use console vim in tmux, I scratched that particular itch by:

1. disabling the automatic opening of the quickfix window when g:dispatch_quickfix_height is 0 (see #208),
2. using a new tmux window instead of a vertical split whenever the callback is possible and g:dispatch_tmux_height is 0 (see #209),
3. proposing to use vim jobs for the callbacks when the GUI subsystem is not available (see #210).

I’ve been using 1 and 2 for some time now and I’m quite happy with it. Those changes are not intrusive, they just give a meaning to otherwise meaningless settings. But it means I have to run vim --servername VIM when I use console vim and want to use those features.

[Cimbali]

I'm afraid I don't use tmux, so I'll keep using this fix. I can remove the reference to this issue @shym (or you can unsubscribe from it) if you're tired of getting notifications every time I pull changes from the master.

[tpope]

So before anything else I really do want to get #210 wired up for both Vim 8 and Neovim, even if it is tedious and boring and easy to procrastinate. After that, I can reduce Vim 7 compatibility to sync only, and we can actually look at changing some of these rules.