[question] how to set it up with gopls ?

[bokunodev]

how to set it up with gopls ? it didnt show the diagnostics. here is my init.lua file

local lsp = require('lsp')
lsp.server_commands.go = 'gopls'

buffer.additional_selection_typing = true
buffer.eol_mode                    = buffer.EOL_LF
buffer.tab_width                   = 4
ui.maximized                       = true

[orbitalquark]

I haven't tested LSP with many servers. What I would do is add require('lsp').log_rpc = true to your ~/.textadept/init.lua and inspect the RPC logs to see if everything is okay.

[bokunodev]

with .log_rpc = true. it gave me this. lua: ${HOME}/.textadept/modules/lsp/init.lua:603: ${HOME}/.textadept/modules/lsp/init.lua:199: No project root found

[orbitalquark]

Okay, when you open a Go file, the LSP module attempts to determine the project it belongs to so that it can send that information to the language server. A project is recognized when it under source control (e.g. hg, git, svn, etc.). If your project is not under source control, then you can simulate it by creating a ".hg" or ".git" directory in the project's root directory.

[bokunodev]

idk what to look for. the diagnostic didnt show up, but i can triger it manually by trigering autocomplete, signature help etc. test.txt

[orbitalquark]

Okay, diagnostics are being sent from the server to Textadept for fileserver/cmd/main.go:

12:1: wd declared but not used
13:51: undeclared name: d

Are these diagnostics not showing up on lines 12 and 13? You haven't set require('lsp').show_diagnostics = false or toggled the menu option "Tools > Language Server > Toggle Show Diagnostics", right?

[bokunodev]

Are these diagnostics not showing up on lines 12 and 13?

yes, its not showing up

You haven't set require('lsp').show_diagnostics = false or toggled the menu option "Tools > Language Server > Toggle Show Diagnostics", right?

no, i haven't. i did try toggle it off and on to see if anything happen. but the diagnose only show up, when i triger it manually. for example "goto refrence" but there is a syntax error etc. i saw gopls throwing some error, but lsp doesn't always catch it.

[orbitalquark]

What platform are you on?

[bokunodev]

Arch linux i install textadept-lsp by cloning this repo and run make then extract lsp.zip file to ~/.textadept/modules

[orbitalquark]

Thanks. It looks like the asynchronous I/O is having issues with notifications. In your case, notifications are not being sent or read until a separate request is made (e.g. go to reference). I've seen this before on Windows, but I don't know how to properly debug or fix it. I personally don't like to use diagnostics, so I'm not sure when I'll have a chance to look into this, sorry :(

[metaleap]

Just reading through the README, could it be an approach for a user who wants to catch diags near-on-the-fly to have a 1sec-or-so interval func set up in their init.lua that performs

• either a Server:handle_stdout(output)?
• or a Server:read() followed by a Server:handle_data(data)?

Guess I'll before soon play with both avenues... would be sweet if those did the trick I guess

[bokunodev]

as i remember, the problem comes when gopls send notification to the client, but i'm not really remember. i haven't used TA in a long time. after a quick look at LSP spec, notifications, request start with $/ is optional and can be ignored. so the client can just skip every response that start with $/

[orbitalquark]

I'm going to close this one. This module works with gopls. There is some weirdness when it comes to diagnostics and when they show up, but I think it's because gopls sends diagnostics later than expected.

For example, if I have a simple main.go:

package main

import (
  "regexp"
)

func main() {

}

and save it, LSP logs that a "textDocument/didSave" was sent to gopls. I am expecting a "regexp import not used" type of diagnostic, but it doesn't come. When I mouse over "regexp" to trigger a gopls symbol lookup, the first receive I get is a response to my "regexp" lookup, not a diagnostic. The diagnostic comes after the first response. This means that the diagnostic has not been in the message queue and unprocessed. The diagnostic is received and processed, and I get the expected "import not used" message.

If the first receive after my gopls send is the diagnostic, then it has been waiting in the queue and was not processed. That would have been a bug.

Hopefully this makes sense.