Closed ilanpillemer closed 3 years ago
I'll look into adding an environment variable, but you can workaround the issue by creating a symlink that doesn't contain any space to the Application Support
directory .
The config file is read from whatever directory returned by os.UserConfigDir, and I'd rather stick to the convention it's following rather than clutter $HOME with more files.
I didn't think of the symlink option. That is sufficient. Thanks.
I am happy with the symlink solution, just re-opening as I see you added the enhancement label. I am happy for this to be closed.
I think its worth having the ability to override the default config if you're playing around with multiple configs. I find myself doing that often when debugging acme-lsp or gopls.
What if I want to run a crystal lsp python lsp etc and a go lsp. Must I use the same config and have all workspaces in same place?
You should be able to use the same config file for multiple LSP servers. It's simpler to have the same set of workspace directories for all the LSP servers. I think that's how VSCode does it also. The FilenameHandlers
ensures that each language server only receives requests for the filename that matches the pattern.
Some LSP servers don't even care about workspaces, so you may not even have to tell it where you keep your code.
On Darwin the config gets put in "Application Support".. Because of the space in the directory name I am having trouble editing this file in Acme, and have to use Emacs. If I could specify where this file is located somehow (maybe an environment variable) that would be great.
Even better would be just to use a
.acme-lsp.toml
file in~
if it exists.Currently it does this :
// On Darwin, it returns $HOME/Library/Application Support.