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

Make the clients initialize the servers themself #625

Open
saccarosium opened this issue Dec 10, 2024 · 3 comments
Open

Make the clients initialize the servers themself #625

saccarosium opened this issue Dec 10, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@saccarosium
Copy link
Contributor

Hi,
I think we can have a mechanism that lets the various clients initialize the servers for the user.

Taking as an example guile via socket. It is annoying that I have to spin up myself the repl and set the socket. It would be much nicer I do <localleader>cc and then the guile process is spawned by neovim via a job and sets ups the socket for me. I think it can be really easy to make and we can use just a function that can be user customize if needed.

@russtoku
Copy link
Contributor

The Conjure Client already has something like this in the form of the auto-repl (:he auto_repl). This will launch a Babashka nrepl server so that the Conjure Client can connect to it if no nrepl server is found.

So, it seems feasible to add an enhancement to the Guile Client to launch a Guile REPL. It may make sense for some other clients.

Thinking out loud, the conjure.process module could be used to launch a REPL using the command, guile --listen=<socket_name> where <socket_name> is something like /home/user/guile-repl.socket. Then conjure.client.guile.socket (fnl/conjure/client/guile/socket.fnl) could be modified to have some additional config keys for:

  • The command to run the REPL in the background.
  • Enable/disable automatically launching the REPL.

When the Guile Client starts up, it can call conjure.process to launch the Guile REPL using the config set up. It's probably a good idea to have key mappings to stop the REPL that was launched and to start it later.

@Olical Olical added the enhancement New feature or request label Dec 15, 2024
@Olical
Copy link
Owner

Olical commented Dec 15, 2024

Yep this is a per client thing, it's also a per user thing. If I turned this on by default for all clients I'm sure it'd make some people happy and some very unhappy, so we'll need more options and documentation for something like this.

Maybe a global option that all clients should try to respect around auto starting / connecting to REPLs. This is now on my radar, but will need a little thought about how to do it nicely.

Maybe having all clients respect a global option is a good idea, try to unify them into a common behaviour. It'll just be through convention so will require changes in every client which is a bit time consuming.

@russtoku
Copy link
Contributor

In v4.39.0, a global option was added to disable automatically calling a client's on_load function.

Add option to disable client on-load fns #377
on-load is used by clients to trigger auto repls and connections. This
means you can make Conjure a little more passive until you invoke
something that requires a connection / repl.

I implemented code for the Python, snd-7, and SQL clients so that they wouldn't start the REPL connection if g:conjure#client_on_load was set to v:false. Unfortunately, I mentioned this only in the help docs for the SQL client.

It doesn't seem like other clients have implemented code that enables this functionality.

Similarly, I think that each client should handle automatically launching their REPL server on their own. Providing a function to do that and <localleader>cc to execute that function would be nice. Other clients could borrow parts or all of the implementation from the Guile client if needed.

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

No branches or pull requests

3 participants