From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: Language Servers and Emacs Date: Wed, 26 Apr 2017 09:24:24 -0400 Message-ID: <20170426092424.61c925c5@jabberwock.cb.piermont.com> References: <20170411122816.751a130f@jabberwock.cb.piermont.com> <20170412085909.44faf429@jabberwock.cb.piermont.com> <87h91cvfz2.fsf@russet.org.uk> <87tw5chytb.fsf@gmail.com> <20170425220038.57619413@jabberwock.cb.piermont.com> <87tw5b4dyw.fsf@russet.org.uk> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1493213082 23610 195.159.176.226 (26 Apr 2017 13:24:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Apr 2017 13:24:42 +0000 (UTC) Cc: Helmut Eller , Katherine Cox-Buday , emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 26 15:24:37 2017 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 1d3Mvr-0005z5-BU for ged-emacs-devel@m.gmane.org; Wed, 26 Apr 2017 15:24:35 +0200 Original-Received: from localhost ([::1]:55235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d3Mvx-00067B-1f for ged-emacs-devel@m.gmane.org; Wed, 26 Apr 2017 09:24:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d3Mvl-00065h-Sc for emacs-devel@gnu.org; Wed, 26 Apr 2017 09:24:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d3Mvh-0000sM-VJ for emacs-devel@gnu.org; Wed, 26 Apr 2017 09:24:29 -0400 Original-Received: from hacklheber.piermont.com ([166.84.7.14]:60605) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d3Mvh-0000s2-RH for emacs-devel@gnu.org; Wed, 26 Apr 2017 09:24:25 -0400 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 031FD2C1; Wed, 26 Apr 2017 09:24:25 -0400 (EDT) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id DAACC2DE021; Wed, 26 Apr 2017 09:24:24 -0400 (EDT) In-Reply-To: <87tw5b4dyw.fsf@russet.org.uk> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 166.84.7.14 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:214307 Archived-At: On Wed, 26 Apr 2017 12:15:19 +0100 phillip.lord@russet.org.uk (Phillip Lord) wrote: > > I suspect that most of the ways of interacting with external > > language tools other than LSP will fade over time, but whether or > > not that's the case, it clearly seems to be smarter to have an > > external language tool than to have to duplicate the work of > > parsing and managing symbol tables inside the editor. > > Well, this depends whether LSP is good or not. You might re-read what I was saying. It is more general than LSP. My point was that whether _LSP_ is the One True Way or not, the idea of interacting with language tools to get information about the program instead of building a parser for every language into the editor is clearly a good one. So that doesn't depend on whether LSP is good or not. :) > Even then, history > suggests that introduction of the one true standard, just results > in yet another technique for the same thing. > > A brief look at LSP seems that it's relatively limited in scope, > though; it has some discussion of "capabilities" and "execute > command". How extensible is it? For instance, NREPL allows evalling > code, or loading files? Would it be possible to send enough data > through LSP to support edebug step through debugging for instance? It's really intended for helping editors out, but it is extensible. Have a read: https://github.com/Microsoft/language-server-protocol https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md -- Perry E. Metzger perry@piermont.com