-
Notifications
You must be signed in to change notification settings - Fork 25
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
Asynchronous build support #2
Comments
Plugin use Continuing our internal discussion. Both vim and neovim use different async mechanisms, and the reason why I want to use neomake is, because it supports both editors (I didn't see this point addressed in the responses). The alternative is for us to write the async handling code ourselves. In that case, I would write for both versions since, I am using neovim myself. So I figure, trying out with neomake first, saves us from writing code at the expense of user having to add one more plugin to her settings. This trade-off seems OK to me, the user already has to download the bazel + maktaba plugins, so it's not like she's practicing ascetic approach to vim :). Given that information, what's your opinion now? Interface Let's continue also our discussion about the interface: What do you think about:
Some alternatives are:
|
I'm behind the idea of using neomake, as I was actually hacking on doing just that already. |
My big question is will neomake support all the functionality we'll ultimately want? I admit I may just not understand how to use it properly, but I found a lot of apparent limitations. Doesn't seem to support any interactive terminal view of jobs and I'm anticipating limitations in how it handles quickfix. Other comments:
OTOH, I'm a diehard idealist and you're the one volunteering to write code. What are your thoughts on all those tradeoffs? |
Let's focus on interface and features first - the implementation will follow
That's true that neomake has a specific workflow in mind, and we may have to ditch it if we can't fit our features into its model. That's why I'm trying to get some sense of what kind of workflow we have in mind. The interface that I roughly described in initial posts would be supportable by neomake. Interactive terminal? Not much, at least without resorting to hacks. I would like to go a more idealistic route myself, so let's agree on what kind of stuff we want there to be in the plugin, and, then, we'll figure out how to support them. If neomake's model doesn't allow us to implement all the features we want, then I'm OK with implementing our own async job adapter around vim 8 and neovim (I did something similar and basic for vim-airline - excerpt). Are you OK with that? Batteries included So, working out of the box, without an additional plugin, necessitates our own implementation. Do we want to have this batteries included philosophy? Interactive terminal The terminal stuff, would require a fully functional adapter. However, I don't fully understand how that terminal would work. To get a terminal output of a blaze job, the blaze process needs to be attached to a terminal from the start. In neovim I could start a :terminal in the background and run the blaze asynchronously in there (already a bit hacky). I don't know how it would work in vim 8. Do we really need a terminal? Can't we just have :BazelCancelJob, and :ShowBazelOutput that would open a text file with current or last output of a bazel job? |
I think if we're leaning towards using a terminal/showing the output in a buffer, then we should also think about the experience of running If we could magically also populate the quickfix after running those commands, this would be perfect, but I don't know how I would do that (maybe some shenannagins with EDIT: |
An interactive terminal view isn't necessarily a "must", but looks straightforward to implement in vim 8 at least. I think we'd want some kind of "view log" operation if we didn't have a live view, so I could imagine neovim falling back to just showing the latest contents of the log if neovim really couldn't show it interactively. I'm not super attached to that view being embedded into vim either, I'd just expect to be able to watch it in a terminal somehow in my workflow. Re "batteries included", I'm not particularly opposed to having plugin dependencies, but depending on plugins that aren't made to be depended on can get weird. And it seems like delegating everything to Neomake adds significant limitations without actually saving much maintenance burden in practice. I expect a few conditionals like what you linked to in vim-airline, doable if not trivial AFAICT. Re quickfix, it's always possible to populate it after the fact using |
It doesn't look straightforward to me at all. Could you elaborate on how it would work? Looks to me that we feel comfortable with working directly with vim 8's and neovim's async inferface. I'll start hacking the most important features, keeping in mind that it has to support the fancy stuff you mention. |
Jobs and channels can set a |
There can be an option to use |
@ngzhian consider using BEP's TestResult instead of parsing the stdout? |
It doesn't look like TestResult contains information about build failures. In the event of a compile error (say in a java file), the error output is stderr of the Progress message. So it will still have to be parsed. |
If you invoke a slow bazel build that takes seconds or minutes, the build will currently steal focus and execute in the foreground, preventing you from doing anything else in your vim session until it finishes. It would be nice to have the build continue in the background and leave vim fully usable while it's running (possibly in some kind of interactive shell mode where you can see the bazel cli output as it's printed).
Vim 8's new job support looks like it will suit our needs. In Neovim, there's probably a native API to do what we want.
The text was updated successfully, but these errors were encountered: