Request: eglot-ensure in an async manner

[jojojames]

I am using KotlinLanguageServer (https://github.com/fwcd/KotlinLanguageServer) and using

(push '(kotlin-mode . ("kotlin-language-server")) eglot-server-programs)
(add-hook 'kotlin-mode-hook #'eglot-ensure)

kotlin-language-server takes a very long time to start up (upwards of 20-30 seconds) which blocks emacs from opening the file until the server is done starting up.

I've tried with/without eglot-ensure along with that server to narrow it down to this language server. (O f course there could be some other interactions between different packages).

Could provide a smaller emacs -Q repo if that would help but I think the main challenge is compiling the server.

[joaotavora]

Of course there could be some other interactions between different packages

No, I think I've seen slow server startup time mentioned somewhere already.

Could provide a smaller emacs -Q repo if that would help but I think the main challenge is compiling the server.

Yeah. For this rather put a dummy "sleep" somehwere in the invocation of any other server than spend time messing with Javaland. I will add kotlin to the README.md tho (or take your PR that does it).

[terlar]

I see similar slowness during the start of bash-language-server, so I don't think it is unique to that server. Although not that long, it blocks around 2-3 seconds when opening the first bash script that starts the server.

[joaotavora]

Regarding the actual problem. I think lsp mode suffers from this problem too. It's not particularly hard to fix, I think. I'm actually thinking a hybrid scheme: Wait up to N seconds synchronously, then wait asynchrously.

The hard part here is eglot-ensure: if you don't block until something happens you're not really "ensuring" anything, are you? It's a question of semantics though: i think we can say that we "ensured that we tried" :-)

[jojojames]

I will add kotlin to the README.md tho (or take your PR that does it).

I'll PR something for kotlin when I get some free time.

The hard part here is eglot-ensure: if you don't block until something happens you're not really "ensuring" anything, are you? It's a question of semantics though: i think we can say that we "ensured that we tried" :-)

Something like eglot-start-async or whatever would work for me but the naming was never too important for me anyways!

[joaotavora]

I've pushed a commit to fix this. Its failing some tests (and I don't know why exactly yet), so it's not ready to go to master.

However, I would appreciate it if you could give it some testing. eglot-sync-connect is the new defcustom you should look to. Tell me if the docstring is legible (I didn't double-check those bits) and if you understand how it works. Then tell me if it did work like you wanted it to.

[jojojames]

I think eglot-ensure with the latest commit (on your async branch) doesn't seem to connect anymore for me.

I'll describe it symptomatically as I didn't have enough time to do some digging. For most variations of eglot-sync-connect (even t ,don't quote me on t,), emacs will print out a message saying 'connected, eglot managing, ...' but the mode-line indicator doesn't change ([eglot:kotlin] for example is not added) (or something similar, I'm going off memory).

Completions/etc don't seem to be working either.

Given that aside, if it did work (eglot connecting everything), the asynchronous mechanism seems to be working well.

Switching back to the commit right before (without the new defcustom) produces the synchronous eglot-ensure that works for me (flymake providing diagnostics, completions working, etc).

If you point me to where I should be looking, maybe I can dig up more info for you.

As for the docstring,

(defcustom eglot-sync-connect 3
  "Control blocking of LSP connection attempts.
If t, block as long as a .  A positive
integer number means block for that many seconds, and then wait
for the connection in the background.  nil has the same meaning
as 0."
  :type '(choice (boolean :tag "Whether to inhibit autoreconnection")
                 (integer :tag "Number of seconds")))

If t, block as long as a .

I don't know what this means but I assumed it meant to just restore similar behavior to before.

nil has the same meaning as 0

I think I can guess the conclusion of nil == 0 but I think it would be clarifying to explain what 0 does (e.g. don't block at all). I assume that's the case but maybe someone else would be confused.

[joaotavora]

Thanks for the feedback. Seems there's still quite a bit of work to do.

You're right about the docstring, even if it's missing part of a sentence

[joaotavora]

@jojojames I've updated the branch. It's still failing tests when the suite runs non-interactively (have to check that). But you can try again and all the other problems (completion, etc) should be gone.

[jojojames]

Thanks, works for me. Docstring is also ++.

[nickyr]

Hey! Thanks for making this. I am a n00b at elisp. Is this the correct way to use eglot-sync-connect if I want no blocking at all?

(setq eglot-sync-connect 0)
(add-hook 'php-mode-hook 'eglot-ensure)

[joaotavora]

According to the doc, yes eglot-sync-connect is a variable defined in `eglot.el'. Its value is 3 Documentation: Control blocking of LSP connection attempts. If t, block for `eglot-connect-timeout' seconds. A positive integer number means block for that many seconds, and then wait for the connection in the background. nil has the same meaning as 0, i.e. don't block at all. You can customize this variable. [back] Let me know if it really works that way :-)

…

On Thu, Nov 8, 2018 at 4:24 PM Nicky Robinson ***@***.***> wrote: Hey! Thanks for making this. I am a n00b at elisp. Is this the correct way to use eglot-sync-connect if I want no blocking at all? (setq eglot-sync-connect 0) (add-hook 'php-mode-hook 'eglot-ensure) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXnwyTbakxTHcHS7mt-DY0fBC0ecSaHks5utFqjgaJpZM4V3f4B> .

-- João Távora