[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Elisp LSP Server

From: Dmitry Gutov
Subject: Re: Elisp LSP Server
Date: Mon, 11 Oct 2021 02:45:14 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 10.10.2021 15:48, Ag Ibragimov wrote:
LSP, for many Emacsen has become a true game-changer. You don't have to 
re-invent the wheel for every single different language, no need to map and 
re-map the keys (separately for every language) or struggle when a language 
mode package authors fail to include some features.
Wouldn't it be ironic if soon, Emacs gets truly fantastic support for dozens of 
languages (btw, that list is still growing), yet Elisp would have to ride like 
a second-class passenger?

I see where you going with this: if we just consolidated our languages support code as an LSP client and moved Elisp implementation to an LSP server, we might be better able to focus on a language support UI which is the same across languages.

Unfortunately, it's not so simple: even aside from the JSON transport (which we could get around by offering different transport options), the LSP protocol has limitations which would limit us on certain features.

For example, you can 'C-u M-.' in an Emacs Lisp buffer, then press TAB and see all the available symbols you can navigate to; I'm told this is either impossible to support with the current LSP protocol, or pretty hard to do.

Other examples are in how completions information is presented; it's basically tailored to VS Code's completion popup. LSP clients are saddled with certain drawbacks when you use company-mode.

Maybe someday.

Instead, we're currently focusing on reusable UI workflows.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]