Skip to content

AbortDispatch not aborting full request stack #302

@maxigit

Description

@maxigit

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions