asyncrun.vim
asyncrun.vim copied to clipboard
skywind3000
Added `-unique=?` to `-mode=term` & `*edge` options to `-pos=?`
This pull request adds the -unique=? flag as an option in terminal mode such that only one terminal with this flag may be spawned at a time in any tab page. If a second terminal with this flag is spawned, the previous one will be automatically closed. This differs from the current behaviour of -reuse=1, where a new window will still be created unless the previous command has finished executing (which sometimes, undesirably, leads to a number of similar/identical terminal windows being opened that must then be manually closed).
To compliment this flag, I've also added the topedge, bottomedge, leftedge, and rightedge options to -pos=?, so a terminal may now be used like the quickfix window, e.g. via:
:AsyncRun -mode=term -pos=bottomedge -rows=16 -unique=1 $(VIM_FILETYPE) "$(VIM_FILEPATH)"
Running this command twice in any tab page will open a new terminal window below all other windows and always close any previous terminal instance created in this way (in the current tab page) before launching the new one.
An alternative solution, instead of creating the new -unique=1 option, would be to add a -reuse=2 option instead, since I can't think of any scenario where someone would want to have -unique=1 and -reuse=0 (but maybe there's some fringe case I'm overlooking?). So, if you would like to merge this but feel -reuse=2 is a better option I can always create a separate pull request for this.
Thanks, -unique is a good idea to reuse windows, but is it unique to a window or to a buffer ??
People using buffer swithcing may switch the previous terminal to another file, and some of your autocmd's may fail after that.
No problem. It's unique to a tab; although I suppose I could implement a unique option for windows or buffers too if there is any demand (and an agreed upon method for triggering this)? For my use case, reusing a terminal for tasks on the current tab is sometimes handy though.
People using buffer swithcing may switch the previous terminal to another file, and some of your autocmd's may fail after that.
In my testing this doesn't seem to be an issue, since the current job of any terminal window must be force ended before the window may be used for another buffer; in which case the code I've added drops the unique terminal id for the current tab so another unique terminal window may be created.
OK, I got your idea, if you don't mind, I will close this and implement in my flavor way later.