You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Without argument
:AbortDispatch
only abort the last request even though this request is completed , ignoring request still running in the stack (s:makes
). I usevim-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
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
)with
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 ...)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 usingtbone
) 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.The text was updated successfully, but these errors were encountered: