From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Vibhav Pant Newsgroups: gmane.emacs.devel Subject: Re: lsp-mode in GNU ELPA? Date: Sun, 18 Feb 2018 01:43:26 +0530 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1518898320 21021 195.159.176.226 (17 Feb 2018 20:12:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Feb 2018 20:12:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 17 21:11:56 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1en8pr-0004rz-PD for ged-emacs-devel@m.gmane.org; Sat, 17 Feb 2018 21:11:51 +0100 Original-Received: from localhost ([::1]:58634 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1en8rt-0000so-RI for ged-emacs-devel@m.gmane.org; Sat, 17 Feb 2018 15:13:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1en8rm-0000qR-8I for emacs-devel@gnu.org; Sat, 17 Feb 2018 15:13:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1en8rk-0008CM-Ur for emacs-devel@gnu.org; Sat, 17 Feb 2018 15:13:50 -0500 Original-Received: from mail-yw0-x22d.google.com ([2607:f8b0:4002:c05::22d]:43470) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1en8rk-0008C4-Pm for emacs-devel@gnu.org; Sat, 17 Feb 2018 15:13:48 -0500 Original-Received: by mail-yw0-x22d.google.com with SMTP id p70so372058ywg.10 for ; Sat, 17 Feb 2018 12:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L5A9XDJqUlFqhmuW0DaTrliPygtPXofxGXCES6v2LPw=; b=LA3gQqRVx8f/PowY+9oMNu9XruuVEauvX7thR3xcSUMobBt1OsjvwzI+lcI7Li0X8G qs0M7eMaD+GiaO5mcxobIl7bBVSBZ0jeWLj+MA6PcXR689SZhqBGm7oQHC73mxKOMwEE o7C3ooOSxE0sPnmDP/Q5QOyp4uYgMyanUBRYPMZwGSpK4a7C+dSwTTGQ4EsUbVfTfb+w QKdOYkcxoDK+MsSK4nSCeEAniOQnpaznzbDDomLBCqb9tYzguxxcL95K7HdS2lRfwCds jZ/p4vOQ+vK9TkByljGqcwIUeRzsAegWK3wVbGFUBBxhL9HejgWsEPozVCbY8L9jSYsf xLkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L5A9XDJqUlFqhmuW0DaTrliPygtPXofxGXCES6v2LPw=; b=uCBrY92ZUQRD2vTRNHeavAAVCLK4cgzHrQtEr8V+4JCI1cFlG+QpDMFQyJQOeKR1W6 /FjyB1iaSAwh20xOESYSg+6EHnye+2c6AaMFg+6wXYALZFY4ieQ8Cmh53iJ+zwGxrbLA Es+Ic/diMDkgQbG0JfqKO+Xyi4lBeGc1uS6Mm7jwTdoIbQuh7onuUQ3iEOLHJaX5SaRr AwwWJjdsR6AvuGLqzskp1IXT1O08V1V4N8SFFepTkpIxjgGZkKOO31J0Kk098sHd0Td6 ynprdJ4PJqizAfqzsksfA1mRURZBzP5GYa1p1pzC7U7hec1B15LhgRnEBCAhXQsn/Adv K2XQ== X-Gm-Message-State: APf1xPDUp8oq96ydjuNXduvY6ueqNcBWGRrJ47grXAa7P3YdcIYl5ZYq qo+jzOOvVzNQzPh8W/FwUEXtm0Tn0e4VBE4LZdsKGelL X-Google-Smtp-Source: AH8x227SxEfyzZ9tr3WXiwAep23V88nogmYwPHrmGJ+6UHBO+epj1gdtz38Cza7bmugvbfjTg5U2sJcQqg4JQbWmACc= X-Received: by 10.129.39.199 with SMTP id n190mr6891033ywn.5.1518898427103; Sat, 17 Feb 2018 12:13:47 -0800 (PST) Original-Received: by 10.129.50.77 with HTTP; Sat, 17 Feb 2018 12:13:26 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4002:c05::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222865 Archived-At: Hi Stefan, On Fri, Feb 16, 2018 at 9:31 PM, Stefan Monnier 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 vibhavp@gmail.com