Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usage via TRAMP #182

Open
MichaelXavier opened this issue Sep 25, 2019 · 1 comment
Open

Usage via TRAMP #182

MichaelXavier opened this issue Sep 25, 2019 · 1 comment

Comments

@MichaelXavier
Copy link

I've got a purescript project that I need to edit remotely over TRAMP. I've ensured the remote machine has spago and friends. However, when I ran psc-ide-server-start from a purescript buffer and gave it the dir that containts spago.dhall, it couldn't find spago. I suspect that's actually the core issue going on here.

I determined that it was actually running the command locally because the output was different once I installed spago on my local machine. Now running psc-ide-server-start produces the following *SPAGO ERRORS* buffer:

spago: There's no "spago.dhall" in your current location.

If you already have a spago project you might be in the wrong subdirectory,
otherwise you might want to run `spago init` to initialize a new project.

Even though there definitely is a spago.dhall in the directory I give to psc-ide-server-start.

From what I've gathered so far, start-process can be replaced with start-file-process which is equivalent except when started from tramp it is smart enough to spawn the process remotely. Likewise, call-process becomes process-file. I've tried making these modifications to my copy of psc-ide.el but this didn't resolve the issue.

I think maybe a pragmatic and easy solution (if possible) would be to allow you to invoke psc-ide mode and just assume that the process is already running and talk to it over port 4242 or whatever, perhaps a variant of start that takes the host and port. Then, folks working on remote servers can just start the process themselves and either port forward or supply the whole host.

@kritzcreek
Copy link
Collaborator

Sorry I meant to reply to this, I just forgot about it. I've never tried to run the ide server remotely, but the plugin should work just fine with an ide server started outside of Emacs. I don't know if it works fine with a remote process though, because there are some file paths that are being passed back and forth (that's a problem with the protocol rather than the plugin though).

I didn't make an effort to secure the ide server in any way, which means you really shouldn't expose it on a public port (just something to be aware of if you want to experiment with this).

If you get this to work and the changes aren't too intrusive I'd consider taking a patch and try to keep the thing working across future changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants