search

idanarye / vim-vebugger

Yes, we do need another debugger plugin
http://www.vim.org/scripts/script.php?script_id=4941
424 stars 35 forks source link

Neovim jobstart and vim job #26

Open fntlnz opened 8 years ago

fntlnz commented 8 years ago

I noted that you used vimproc#system in order to execute commands in an asynchronous way.

At the moment, Neovim and Vim (since patch-7-4-1590) are both supporting asynchronous commands.

I thought that Neovim users and vim users with has('job') && has('patch-7-4-1590') can benefit from that APIs so the plugin could just use another strategy to run commands for such users without the need to install vimproc at all.

What do you think?

idanarye commented 8 years ago

Neovim may actually benefit from the async nature of it's job API, but from what I understand about Vim's new job API(I didn't actually try it - just read the discussion about it in the) you still need to manually and synchronically invoke the stream reading - which is pretty much what I get from vimproc. So other then losing that dependency there won't be any benefit for Vim users.

At any rate, I still want to support Vim 7.3(I'm actually making some code-style sacrifices to support it...), which means I'll have to maintain 3 versions of the piping wrapping layer. It's not that big(less than 100 LoC), but still not something that I'm that looking forward to do...

idanarye commented 8 years ago

I've looked a bit more into Vim's new job API doc's, and it seems like I was wrong - it's also async.

fntlnz commented 8 years ago

Yes it is, but unfortunately is not available on 7.3 and on some 7.4 - one could handle this btw

bstaletic commented 7 years ago

Does vim's job api have still have a chance of getting support from Vebugger? I'd love to try this plugin, but as long as I have to compile a dependency I'm going to stay away from it.

idanarye commented 7 years ago

There is always hope - but I can't promise when I'll have time to actually work on it.

It'll be a great excuse to raise the minimal requirements to Vim8(/Neovim) though - by the time I get to work on it it should be common enough...

bstaletic commented 7 years ago

Thanks for the replay.

I've tried this plugin and it works great. I played a little with implementing the vim8 job feature, but am now having some troubles. I've seen that you call a vimproc function ony on three lines and two of those (both using vimproc#system) were almost trivial to replace. vimproc#ptyopen, however, proved to be much more complicated.

It calls a lot of other functions some of which could be avoided if commands being passed were lists instead of strings. The other thing that makes this not trivial is that it calls the fuctions written in C part of the vimproc.

On the other hand, the vimproc#ptyopen is only used to get the debugger.shell dictionary. Out of many properties vimproc#ptyopen returns only a few are used:

  1. self.shell.is_valid - As far as I can see, it should be the equivalent of vim's job_status()
  2. self.shell.kill(15) - This is equivalent of vim's job_stop()
  3. self.shell.stdin.write - I have not yet found a vim equivalent
  4. debugger.shell.stdout - Have not even looked at it yet
  5. debugger.shell.stderr - Have not even looked at it yet
  6. self.shell.checkpid - Vim's job's id could be parsed. Only the second field is required.

Do std(out|in|err) need the amount of information provided by vimproc? Maybe we coud trim it for vebugger's specific use case? Any questions, or suggestions would be welcome.

idanarye commented 7 years ago

I was using vimproc#system as a replacement to Vim's builtin system because on Windows system opens a console window. Since vimproc is already a dependency I was using it to avoid displaying that window. As you said - these will be easy to replace.

As for vimproc#ptyopen, this is not a matter of replacing every function - the architecture needs to be replaced. Vimproc needs to work in Vim's single-threaded model: it's functions can be called and return values, but during that time Vim must be frozen. They can't interrupt Vim, so you can't set a callback and go on until you receive output and the callback will be invoked. I had to use the CursorHold trick to periodically check for new output from the debugger.

Vim's(and Neovim's) new job mechanism is the exact opposite. You create a job and set output listeners, and when Vim detects output it will call the listeners as part of it's events loop. We can emulate vimproc's behavior with ch_read, but Neovim does not have an equivalent function and I wish to keep the Vim implementation and the Neovim implementation as close as possible.

I'm already emulating an asynchronous model on top of vimproc's synchronous model. I don't want to emulate vimproc's synchronous model on top of the asynchronous model, only to put Vebugger's asynchronous model on top of it - it's a lot of layers for inferior result. I really prefer to remove a model-switch instead of adding one, and use Vim's new asynchronous model as a direct base for Vebugger's asynchronous architecture.