Find and run the server locally

[ecofighter]

Currently, when editing remote files, copilot.el searches for the executable on the remote system and launches the server remotely. This PR fixes that behavior by ensuring both the executable search and server launch occur locally.

• Change executable-find second argument to nil in copilot-server-executable to search locally.
• Change default-directory to local home directory when it is a remote directory in copilot--start-server and copilot-install-server.
  This ensures processes run with the local home directory as their working directory.
• Remove executable existence check in copilot--start-server since it's already verified in the copilot-server-executable function.

Fixes #403

[bbatsov]

You can just remove this param - it's optional.

[ecofighter]

fixed

[bbatsov]

Same here.

[bbatsov]

I'm not sure what this is trying to solve - I don't think it will have any effect on the executable-find call.

[bbatsov]

Ah, you want it to search only the local filesystem. As noted in another remark - I have some doubts about this approach as I think this might be quite surprising to some people.

[bbatsov]

Change default-directory to local home directory when it is a remote directory in copilot--start-server and copilot-install-server.

Doing this might be super confusing, though, as I'm not sure anyone editing something over TRAMP would expect something like this to happen.

[ecofighter]

Change default-directory to local home directory when it is a remote directory in copilot--start-server and copilot-install-server.

Doing this might be super confusing, though, as I'm not sure anyone editing something over TRAMP would expect something like this to happen.

The change is scoped to lexical scope only. By using let, default-directory is only modified locally within these specific functions (copilot--start-server and copilot-install-server).

I've confirmed that default-directory maintains its original value and find-file and eglot works expectedly. I think the user's TRAMP editing context remains preserved in all other operations.

[bbatsov]

I've confirmed that default-directory maintains its original value and find-file and eglot works expectedly. I think the user's TRAMP editing context remains preserved in all other operations.

Do you know how Eglot behaves when dealing with TRAMP? Does try to start LST servers locally or remotely?

My point was mostly that I'm not sure if when I edit something remotely I'd expect it to trigger the creation of a local process, but I haven't used TRAMP much in ages and I'm not sure what are the common practices there these days.

[ecofighter]

Do you know how Eglot behaves when dealing with TRAMP? Does try to start LST servers locally or remotely?

My point was mostly that I'm not sure if when I edit something remotely I'd expect it to trigger the creation of a local process, but I haven't used TRAMP much in ages and I'm not sure what are the common practices there these days.

Eglot runs LSP servers remotely when used with TRAMP. I've tested this, and LSP servers run remotely as expected.

According to TRAMP's document (https://www.gnu.org/software/tramp/#Remote-processes), the location where processes run depends solely on the default-directory value:

TRAMP supports starting new running processes on the remote host for discovering remote file names. Emacs packages on the remote host need no specific modifications for TRAMP’s use.

This type of integration does not work with the ftp method, and does not support the pty association as specified in start-file-process.

process-file and start-file-process work on the remote host when the variable default-directory is remote:

(let ((default-directory "/ssh:remote.host:"))
  (start-file-process "grep" (get-buffer-create "*grep*")
                      "/bin/sh" "-c" "grep -e tramp *"))

But I'm also not very familiar with the current common practices around TRAMP.

[bbatsov]

@ecofighter I'm guessing it'd be best if we try to run the server locally for local files and remotely for remote files (I guess for remote files we can also elect to not do anything) to be aligned with how LSP packages work in general.

[ecofighter]

@ecofighter I'm guessing it'd be best if we try to run the server locally for local files and remotely for remote files (I guess for remote files we can also elect to not do anything) to be aligned with how LSP packages work in general.

I understood.
I'll close this PR and try a new approach as you said.