Closed dsrw closed 10 years ago
Zed supports a number of different "back-ends", i.e. file system implementations:
A Chrome app cannot spawn subprocesses, so the only way that could happen with the last option (WebFS) because Zed controls the zed
binary and basically could let it do whatever it wants (including spawning subprocesses). However, that would mean you can only use these linters when editing files on remote servers.
Alternatively, you could build a checker module that in fact sends a HTTP request to a remote server containing the code to be checked in the body and taking the result of the linting back. The advantage here is that it will work no matter where your files are stored, two drawbacks are that 1. you need Internet connectivity and 2. you have to ship off your code to some remote server and not everybody may be comfortable with that.
For me, the best solution is to port whatever tools I need to JavaScript. Hence js-git On Dec 9, 2013 9:35 AM, "Zef Hemel" notifications@github.com wrote:
Zed supports a number of different "back-ends", i.e. file system implementations:
- SyncFS (used for Notes and Settings), which uses Google Drive for storage
- LocalFS (for opening local folders)
- Dropbox
- WebFS (for editing files on remote servers)
A Chrome app cannot spawn subprocesses, so the only way that could happen with the last option (WebFS) because Zed controls the zed binary and basically could let it do whatever it wants (including spawning subprocesses). However, that would mean you can only use these linters when editing files on remote servers.
Alternatively, you could build a checker module that in fact sends a HTTP request to a remote server containing the code to be checked in the body and taking the result of the linting back. The advantage here is that it will work no matter where your files are stored, two drawbacks are that 1. you need Internet connectivity and 2. you have to ship off your code to some remote server and not everybody may be comfortable with that.
— Reply to this email directly or view it on GitHubhttps://github.com/zedapp/zed/issues/53#issuecomment-30112601 .
I agree that porting to JS is ideal, but it isn't realistic for my purposes unfortunately.
It seems like zed
running in --client
or --local
should have an endpoint to execute a process and return its output, and another endpoint to execute a long running process and return a ws:// url that chrome can connect to for IO. Does that seem reasonable?
Closing for now. I'll submit a PR if I get this working in a reasonable fashion.
I'm tinkering with subprocess support for things like non-JS linters, test runners, ack/ag search or a SLIME type mode. Thoughts on the best way to implement something like this?