Problems Launching Language Server

[eric-hemasystems]

I'm attempting to try out the newish lsp functionality in Textadept but having problems getting it to launch the LSP. I'm specifically looking to use the ruby-lsp.

My first (probably naive) attempt is:

local lsp = require('lsp')
lsp.log_rpc = true
lsp.server_commands.ruby = 'ruby-lsp'

When I review the LSP logs I see:

Starting language server: ruby-lsp
RPC send: {"params":{"processId":null,"clientInfo":{"name":"textadept","version":"Textadept 12.3"},"rootUri":"file:///Users/me/.textadept","capabilities":{"textDocument":{"synchronization":{"didSave":true},"signatureHelp":{"signatureInformation":{"documentationFormat":["plaintext"],"activeParameterSupport":true,"parameterInformation":{"labelOffsetSupport":true}}},"completion":{"completionItem":{"documentationFormat":["plaintext"],"snippetSupport":true,"preselectSupport":true},"completionItemKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]}},"publishDiagnostics":[],"hover":{"contentFormat":["plaintext"]},"documentSymbol":{"symbolKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]}}}}},"id":1,"method":"initialize","jsonrpc":"2.0"}
Unable to start LSP server: /Users/me/.textadept/modules/lsp/init.lua:466: attempt to index a nil value (local 'line')
stack traceback:
	/Users/me/.textadept/modules/lsp/init.lua:733: in metamethod 'index'
	/Users/me/.textadept/modules/lsp/init.lua:466: in method 'read'
	/Users/me/.textadept/modules/lsp/init.lua:492: in method 'request'
	/Users/me/.textadept/modules/lsp/init.lua:273: in function </Users/me/.textadept/modules/lsp/init.lua:263>
	[C]: in function 'xpcall'
	/Users/me/.textadept/modules/lsp/init.lua:731: in function 'lsp.start'
	/Users/me/.textadept/modules/lsp/init.lua:1275: in function </Users/me/.textadept/modules/lsp/init.lua:1261>
	...tadept.app/Contents/Resources/modules/textadept/menu.lua:516: in function <...tadept.app/Contents/Resources/modules/textadept/menu.lua:513>
	[C]: in function 'pcall'
	...cations/Textadept.app/Contents/Resources/core/events.lua:419: in function 'events.emit'

From this discussion this maybe means it didn't boot the LSP server.

I'm not really sure the best way to debug this, but my hunch is because ruby-lsp is not globally installed. I use asdf to manage various languages and language versions so there isn't a global installation of Ruby. There are many installations of Ruby and my shell switches between them based on the current working directory, etc. So my next thought was to try running it through the shell updating my config to look like:

lsp.server_commands.ruby = '/bin/zsh -c ruby-lsp'

No luck.

Thought maybe it needs the -i flag to force it to be interactive so that .zshrc is read and asdf is setup so also tried:

lsp.server_commands.ruby = '/bin/zsh -i -c ruby-lsp'

Still no luck. Any suggestions on how to resolve this. I'm not even 100% sure it due to asdf but it's my best guess.

---

Followup. I am getting luck with solargraph, an older Ruby LSP. This probably means the asdf is a red herring since I just booted solargraph with solargraph stdio as the command (no zsh wrap or anything). Still doesn't tell me why ruby_lsp doesn't work. I saw you only support stdio but then verified that ruby_lsp is build on a library that also only supports stdio so that should not be the problem.

[rgieseke]

Are you on a Mac?

From the manual:

macOS Tip: by default, macOS does not allow GUI applications like Textadept.app to see shell environment variables like $PATH. (The terminal version is unaffected.) Consequently, any features that utilize programs contained in $PATH (e.g. the programs in /usr/bin/ or /usr/local/bin/) will not find those programs. In order to work around this, Textadept automatically invokes a user-created ~/.textadept/osx_env.sh file when the application starts. This script should export all of the environment variables you need Textadept to see. For example:

export PATH=$PATH

Otherwise using the full path to the ruby-lsp binary might work. Given that asdf changes path order I believe this might also not work as expected.
So maybe asdf which is what you need?

[rgieseke]

Ah, just saw your edit ...

[orbitalquark]

You can use something like io.popen('ruby-lsp --version'):read('a') in Textadept's command entry to see if ruby-lsp is available from Textadept. (I don't know if --version exists, but you would use something similar/equivalent.) If it's available, the message buffer should show something. If it's not available, the message buffer will be blank.

See if ruby-lsp has a log file somewhere. That might shed light on why it's not starting up if Textadept can see it.

[eric-hemasystems]

When trying this out I got some weird behavior. If I just open up something boring like a markdown file and run the above I get back the version correctly (which further confirms asdf and env variables are not an issue).

But when I first tried this I actually got nothing. Not even an empty buffer. After a bit of debugging I figured out that if I had opened a file already that uses an LSP (not even a Ruby one but the Lua one activated when editing my init.lua did it) then your command just seems to do nothing.

---

Outside of that oddity, with LSP completely disabled (so I can run popen without interference), the version comes back so I know it can execute the LSP server. But if I try to run either solargraph stdio or ruby-lsp I get back no output from the command (not even the boot messages). I thought it may be because Textadept is reading on that file before the boot messages even showed but also tried:

f = io.popen('solargraph stdio'); timeout(5, function() ui.output(f:read('a')) end)

Tried the above with both solargraph and ruby-lsp with shorter and longer timeouts and still don't see any output.

I am still wondering if it has something to do with timing. ruby-lsp actually takes a bit to get booted up as it sort of re-packages all a projects dependencies so it can better inspect libraries being used.

---

I'm not too bothered by it not working. To be honest Ruby isn't really a good language for an LSP. Jumping to an impl would be kind of useful but since Rails project follow convention so heavily I pretty much know what file to hit to find an impl 95% of the time anyway. The autocomplete might be handy for cases where the term is not already in a buffer that is open (since I use autocomplete_all_words) but it's not a huge win. Signature help (when the LSP could determine it) would be the most helpful although again due to the dynamic nature of Ruby the LSP is going to be hit and miss on that anyway.

Will continue to play with solargraph since it seemed to have some success. Was just hoping to try out ruby-lsp also so I could try both with Textadept and use the one more useful.

[orbitalquark]

Sorry to hear about all of the trouble. I'm sure it's quite frustrating, but I'm impressed with your debugging. If I understand correctly, io.popen('ruby-lsp --version'):read('a') prints output (i.e. it works) if there isn't currently an LSP instance running (a non-Ruby language like Lua), but if there is, then the io.popen() command doesn't print output (i.e. it doesn't work). That's very odd. I have no idea why that might happen. I don't think it's a timeout issue because io.popen():read() is a direct execute-and-read, and if it doesn't hang the editor, then the command is running (it just doesn't have any output to report).

I suppose the next thing you could try instead of io.popen() is os.spawn('ruby-lsp --version', ui.print, ui.print, ui.print) which should print any stdout, stderr, and exit code from the command. That may shed more light on this.