Minimal changes necessary for having an async Agda process#46
Minimal changes necessary for having an async Agda process#46dolio wants to merge 1 commit intoderekelkins:masterfrom
Conversation
- An autoload script manages the job with vim's async job control - The function to send commands to the process is wrapped into python - The response interpreter becomes a callback that runs as Agda sends output - The `Agda>` prompt is used as a trigger for loading highlighting files, since there is no longer an obvious synchronous point for doing so.
|
Yo. I'm not sure this is completely ready to be merged, but I thought I'd create the pull request to spark discussion. It's the bare minimum of what it takes to make this plugin asynchronous but still work. Here are some discussion points:
|
|
Oh, one thing I didn't do yet (and why it probably shouldn't be merged) is set up any kind of 'command running' mutex like the emacs mode has. That'd probably make for a better way of figuring out when to reload highlighting. Right now you can send commands to agda while it's still working on the previous one. I haven't thought through how things should work, though, since the response interpreter sends some of its own commands right now. |
|
I’m implementing a vim plugin for agda too. |
|
@ray851107 I see. In that case I won't duplicate work, since that's the sort of implementation I would probably aim toward personally. I'm a little confused about the DisplayInfo thing, though. If I log JSON messages those always seem to have null information. Is that the only thing that's going away? |
|
@dolio In the latest release (v2.6.0.1) it returns warnings, error messages etc. In current master it always returns null. |
output
Agda>prompt is used as a trigger for loading highlightingfiles, since there is no longer an obvious synchronous point for
doing so.