Expose per-server wrapper functions for use with nix-shell and guix

[leungbk]

lsp-haskell currently exposes a defcustom, lsp-haskell-process-wrapper-function, to enable a convenient means of specifying a project-specific ghcide executable (for example). This is useful in Haskell since in order to work in a particular project with ghcide, it must be compiled with the exact same version of ghc as the one used to compile the project.

It wouldn't surprise me if some other language server behaved in a similar way. For this reason, it might be nice to expose separate wrappers, defaulting to #'identity, for each language server and debug adapter.

[ericdallo]

As a NixOS user, I agree with that 😄

[yyoncho]

Can this be generalized and handle #1889 as well? Or both will serve a different purpose and will run at different time(flow one when resolving server binary, and this one just before running the server).

Also, we should think of generalizing lsp-register-client. What I wanted to implement in the past by converting lsp-register-client to macro but never had the time is:

1. Auto-generate defcustoms for binaries and parameters. This will unify the experience and it will be easier to document the behaviour, e. g. we can have in lsp-mode docs something like "Go and change the variable lsp--binary-path and lsp--args if you want this and that'. Now we have multiple variables and overall inconsistent behaviour.

2. Have language server specific hook which users could use to customize server specific behaviour. E. g. I would like to enable lenses for rust but hot have them in java.

3. Have language server specific keymaps.

[leungbk]

Can this be generalized and handle #1889 as well? Or both will serve a different purpose and will run at different time(flow one when resolving server binary, and this one just before running the server).

When using nix-shell, you're not expected (but are allowed) to specify the full path of the executable, since the full path looks like /nix/store/hash123abc/.... So I think for #1889 we might want a similar but separate wrapper, generated as part of your option 1.

Also, we should think of generalizing lsp-register-client. What I wanted to implement in the past by converting lsp-register-client to macro but never had the time is:

1. Auto-generate defcustoms for binaries and parameters. This will unify the experience and it will be easier to document the behaviour, e. g. we can have in lsp-mode docs something like "Go and change the variable lsp--binary-path and lsp--args if you want this and that'. Now we have multiple variables and overall inconsistent behaviour.

2. Have language server specific hook which users could use to customize server specific behaviour. E. g. I would like to enable lenses for rust but hot have them in java.

3. Have language server specific keymaps.

All of these sound useful. I had been intending to pursue option 1 for this issue.