Re: lsp-mode in GNU ELPA?

[Vibhav Pant]

Hi Stefan,

On Fri, Feb 16, 2018 at 9:31 PM, Stefan Monnier
<address@hidden> wrote:
> Would you be interested in trying to include it into GNU ELPA (with
> a longer-term goal of bundling it with Emacs)?
>

Inclusion into Emacs has been one of the goals of lsp-mode, indeed. Other than
lsp-flycheck, which is going to be moved to another package and ert-runner,
which we use for running tests, lsp-mode doesn't depend on any non-ELPA or
external packages.

> I see you've already signed the necessary paperwork, but I also see that
> the project has many other contributors, so the main part of getting
> lsp-mode into GNU ELPA will be to collect paperwork for it.  Of course,
> I can help with that work.

We had discussed this on the project github earlier, but never got to actually
collecting paperwork for all of the contributors. Getting all paperwork done
would obviously be a major step towards inclusion.

> More generally, I'd also be interested about your experience with
> lsp-mode, especially in terms of what changes in Emacs could help.

IMO, lsp-mode has achieved a reasonable level of stability over the last few
months. I have been able to accomplish all LSP functionality in elisp without
digging into internal Emacs code (eldoc, imenu, etc). There are still a few
kinks that have to be ironed out for a smoother experience:

1. completing-read/completion-at-point is pretty limited in what completion
candidates can do. LSP allows completion candidates to be linked to certain
command that can be executed when they are chosen. Completion candidates can
also be text snippets, which aren't natively supported in Emacs, AFAIK.

2. thing-at-point doesn't seem to work correctly with syntax like "#include",
which it recognizes as two words/symbols (this might be an issue with the
c-mode syntax table). This can lead to duplicate characters while completing
certain

3. Because after and before change-hooks aren't guaranteed to be bracketed,
the current mechanism for sending changes to the server have to do extra
bookkeeping to ensure that the sent changes are correct. A reliable way
to get the buffer state after and before a single textual change would help
here.

4. There has been a plan to use the native JSON functions in the upcoming
Emacs release for encoding JSON-RPC messages used by the procotol. However,
that is been on hold as `json-serialize` and `json-parse-string` use
:false and :null for representing JSON false and null respectively, which
makes it awkward to work with parsed JSON data. I had submitted a patch
which would allow users to choose alternate objects for representing falsy
values: https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00916.html.

Thanks,
Vibhav

-- 
Vibhav Pant
address@hidden