Skip to content
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

AbortDispatch not aborting full request stack #302

Open
maxigit opened this issue Aug 31, 2020 · 0 comments
Open

AbortDispatch not aborting full request stack #302

maxigit opened this issue Aug 31, 2020 · 0 comments

Comments

@maxigit
Copy link

maxigit commented Aug 31, 2020

Without argument :AbortDispatch only abort the last request even though this request is completed , ignoring request still running in the stack (s:makes). I use vim-dispatch mainly to start repl and I sometime needs two.

To reproduce the bug, start to repl let's say one in python and the other one in ruby by doing

:Dispatch python
:Dispatch ruby

calling :AbortDispatch the first time will close the ruby repl. Doing it a second time won't do anything. :AbortDispatch python will close the python repl.

Fix

My first attempt to fix the bug was to simply "jump" over completed requests when finding the request to abort. This is done with by replacing in (dispatch#abort_command)

let request = s:makes[i]
if strpart(request.command, 0, len(a:query)) ==# a:query
   break
endif

with

 let current_request = s:makes[i]
 if !get(current_request,'completed')  " jump over completed or abort request
   let request = current_request
   if strpart(request.command, 0, len(a:query)) ==# a:query
     break
   endif

However this doesn't allow :Copen to pick the last active request. To fix that I tried instead to move the aborted request at the bottom of the stack (but still at the top of the completed one) with the following code (after the killing the request just before returning ...)

let current_pos = i
call remove(s:makes,current_pos)
let i = len(s:makes) -1
while i >= 0
   let request = s:makes[i]
   if get(request,'completed')
     break
   endif
   let i -=1
 endwhile
call insert(s:makes, request, i+1)

This seems to work well, requests are aborted in order and :Copen works with last active request.
However they probably some side effects to this solution that I am not awere or other way to achieve it.
One way would be
to simply remove aborted request (when aborting them)
, another would be a function cleaning all completed requests
, another would be to be able to change the order of the stack so chose which request is seen as active. This will allows for example to add autocommand to select the active repl depending on tab, buffer etc ...

I'm happy to submit PR as long as you are happy with the way I'm doing it.

Background

Just to clarify, I need two requests at the same (and being able to access their errorfile) because I do Haskell using vim and tmux.
I launch ghci (the Haskell repl) and load the current file with this plugin. At that point I can get some type information from ghci (and send command using tbone) and get them back in vim by either pasting from the quickfix window or opening directly the errofile. With this workflow , the vim-dispatch request is kept alive all the way and I reload the quickfix window all the time (I also have to erase the errorfile to not get previous error twice). I could indeed close an restart the repl instead my project is big and loading a file in ghci requires to load all it's dependencies and can take quite a significant time (thus keep one session alive).

So far this workflow works really well, however one other problem with ghci is when you reload a file with syntax error it stopped at the error and then refuse to answer any usefull question you can ask it (like the type of a function in the same file before it crashes). A way to avoid that is too keep two sessions alive, one to syntax check the current version of the file and one corresponding to the last time it compiled fine . I can do that easily by calling Dispatch twice (on the same file) but I need to be able to abort and read errors for the session I chose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant