Why s:job_supported_types?
Closed this issue · 1 comments
It appears that async.vim is trying to support a theoretical vim program that contained both the vim and nvim job api. Why?
s:job_supported_types builds a list of supported types, but won't there ever only be one type value for each platform? Even you we added a system() fallback, you'd only use that if jobs were unavailable.
I wanted to ask in case I misunderstood something before working on a simplifying PR.
It is there so we can have multiple implementation. For example we could add python or ruby jobs as fallback on older vim that doesn’t support vim job or the recent bugs where it is very slow when sending larger data over pipes.
If it does support manually passing custom job types so that when we have unit tests we can manually test each job type instead of having a build that tries to satisfy the job type.