Language Server Protocol Kills Emacs

By Xah Lee. Date: . Last updated: .

a reddit post sparked a series of long essays by me, relating to emacs lisp, parsers, known hige-powered emacs lisp programers, etc interesting stuff.

The reddit discussion is at
RMS supports Language Server Protocol integration into Emacs core

following are excerpts of my posts.

What is Language Server Protocol

The Language Server Protocol (LSP) is an open, JSON-RPC-based protocol for use between source code editors or integrated development environments (IDEs) and servers, providing programming language-specific features from the language server to the client. The goal of the protocol is to allow programming language support to be decoupled from any given editor or IDE and even have it distributed over independent language servers.[1]

The Language Server Protocol was originally developed for Microsoft's Visual Studio Code. On 2016-07-27, Microsoft announced along with Red Hat and Codenvy that the protocol is being adopted and supported by the three companies.[2][3][4][5][6][7] At the same time, Microsoft made the Language Server Protocol specification an open standard,[3][4][5] hosted on GitHub.[8]

[2017-05-05 ]

[2017-05-05 Wikipedia Language Server Protocol]

Emacs Lisp Sucks. Improve emacs lisp, Not External Tools

Emacs talking to Language Server Protocol (LSP) is certainly a plus. But am taking a wider perspective here.

One thing that's pretty unique about emacs is that it is monolithic. (even so, it is only 100 Mb compiled, while other IDE are few times larger, with few times larger memory footprint) One does not need external tools to use emacs. (only exception is lots of grep related commands, but that's not necessary, as elisp can do and pure elisp packages exist.)

With LSP, it possibly mean that it'll become the norm for emacs to rely on talking to a server. (this is already happening in lots packages.)

Am not saying that emacs should not embrace LSP. But it does dilute emacs uniqueness.

The more critical thing is for progress of emacs lisp. I think we need faster progress here.

Lots packages today, completion and fly-check and lots of others (emacs cinder for clojure), python packages, JavaScript packages, all require you to install gazillion external tools, each requires rather extensive experience to set up properly. And most people don't understand them well. Very complex, prone to break. Upgrade issues. It is just like JavaScript frontend dev now. And the elisp CEDET is very complex, almost nobody uses.

While emacs lisp itself, remains a very dismal language, lacking MAJOR things as really basic string manipulation in core, problematic regex, lacking a NAMESPACE! and is 10 times slower than JavaScript or python. (Note that Atom, Microsoft Code, are all build with JavaScript and using JavaScript as extension language, that are 10 times faster than elisp and 100 times more libraries)

This is 2017, new fancy languages are cropping up almost every month.

It's great that emacs will be able to use LSP, but emacs lisp is falling so much behind. The more behind, the more external tools will become critical. We need progress in emacs lisp.

Today, most emacs users are such that they just use the thousands of packages in melpa. From what i see, fewer and fewer people are interested in how emacs works. It used to be, people constantly are amazed by new emacs commands, methods and ways. That seems to have disappeared some 5 years ago.

If emacs lisp have fixed these critical problems, judging from the number of packages on MELPA, we'd already have lots quality parsers by many talented coders here that would even beat the dedicated external tools.

Grow emacs. Not external tools.

Which Emacs Lisp Hackers Have Written Compiler/Parsers?

It's debatable, but i think there are quite a number of elisp hackers that already or WILL produce parsers in elisp overnight.

for example,

• Marijn Haverbeke, author of “Eloquent JavaScript”, and creator tern.js and tern.el. Marijn Haverbeke is a elisp hacker, wrote JavaScript parser in JavaScript.

• Christopher Wellons [] (aka skeeto), creater of elfeed, and skewer-mode (for live web dev of JavaScript connection to browser JavaScript) Serious elisp hacker.

• emacs flycheck author [[2017-05-04 ]] is also a serious elisp hacker. Flycheck is a big project, connecting to all the other external tools and parsers.

• Phil Hagelberg [] (aka technomancy), creator of Clojure Leiningen , also the creator of (precursor of?) cider (for emacs package connecting to clojure), etc, one major elisp and clojure hacker.

• Stefan Monnier [] , the previous emacs maintainer, professor on function language research (e.g. ML, coq), wrote many many elisp things. (just quickly off top of my brain: css-mode, and a new parser for that now in emacs, and visual-line-mode, etc) He wrote smie.el and pcase.el, both are language tools.

• John Wiegley [] , current emacs maintainer, and haskell/coq hacker, who works on IDE/compiler or such in C++ for some 20 years.

• Steve Yegge [] , author of js2-mode (contains real time JavaScript parser/validator in elisp) and ejacs (fully ECMAScript 5 compliant compiler in elisp)…

• Lars Magne Ingebrigtsen, author of eww mode (full browser in elisp), also author of gnus

• Eric M Ludlam, author of CEDET (IDE parser framework, in elisp).

• James Clark, author of nxml-mode (real-time XML parser/validator), and author of the most used xml parser in C some 20 years ago...

and more.

these folks are some of the key figures in elisp, and many of their code are pillars holding emacs.

if elisp is in much better condition (e.g. not 10 times slow, no namespace, lack basic string/list functions in core), many of these people, or their existing parsers in elisp, may easily beat dedicated external tools outside of emacs. Many externals tools are created by them.

note: about 10 years ago, php, scheme lisp, both don't have namespace neither. But, both have fixed it even 10 years ago. Even, php has begotton hacklang and new compiler, and Scheme lisp has begotton racket lang and pyret. They've move on quite a bit. JavaScript's ES2015 is pretty much a complete new language fully competable head-to-head with any of python ruby. Emacs lisp, basically haven't progressed much. We got closure and lexical binding now, i think that's about it.

Emacs Lisp Lack Basic String Functions

eli, thanks for responding. I agree with your explanation and call for contribution to elisp. And i agree LSP should be supported. I don't have answer on what to do.

but here's why i think elisp lack basic string functions, for what's worth. (i enjoy debate and writing in bikeshed!) I also have some questions, if you happens to know the answer, greatly appreciated.

A function to trim whitespace does exist in core, we just had a discussion about extending it.

i think we are talking about string-trim in subr-x.el. In the header, it says:

 ;; Do not document these functions in the lispref.

subr-x functions are functions which haven't yet proved useful enough to deserve to be in subr.el, so for the same reason I don't think they belong in the Lispref either.


Why is that?

I think that's a problem. e.g. suppose someone read the entirety of elisp manual, and he wouldn't know about these function.

A function to trim string of whitespace is probably used in every text processing task, specifically noted by a emacs leader to not be mentioned in the language manual, and for a language designed for text processing, and in a package one has to load manually by (require 'subr-x), with a package name “subr-x” that doesn't conjure up concept of “string” at all. I find the situation pretty bad.

Similarly, on MELPA, the most popular packages

are meant to fix lisp lack of basic function library problems.

i don't like these packages each calling themselves “modern”, but they are basically functions modeled after modern languages (say, after 2005), each package in their own consistent way, while in many respects, is not consistent with elisp and does not follow elisp conventions. (e.g those 1-letter naming, and function parameters, and the brave word “dash” does not connote “list” at all.)

They been around for some 5 years. I think that emacs's subr-x.el is a reaction to the popularity of “s”. And i think emacs also tried to fix the lack of list functions problem, resulting in a new package “seq.el” in emacs by Nicolas Petton.

what's the status of “seq.el”, e.g. would it be documented in emacs manual?

as far as i know, most emacs dev outside of FSF don't know or use the new elisp ones. They just use the MELPA “s f dash”. This is a problem.

(by the way, someone will probably mention “cl.el”. That's a controversial package among elisp devs. might see my summary of arguments on both sides at Controversy of Common Lisp Package in Emacs Lisp )

[see Emacs Lisp: Trim String]

[see Emacs Lisp Problems: Trim String, Regex Match Data, Lacking Namespace]

ELisp is 10 times slower than JavaScript?

programing language speed 2017 05 05 55175
rough ranking of programing language speed. [image source ]

Evidence that ELisp is 10 times slower than JavaScript?

I have scripts in perl python elisp for find/replace. I use them on about 2 hundred to 4 thousand files in a directory, few times per week for years.

Don't have a scientific data, but am confident to say elisp is 5 to 10 times slower than python for general tasks.

here's the code.

xah-find-replace-text in xah-find.el at

perl and python. (the perl one is 20 years old, python is 10)

not a precise test, and the code don't do exactly the same thing, but i've used elisp and python for many other text processing tasks.

if anyone wants to write a elisp version for a more proper speed test

i'd be interested in result too.

by the way, JavaScript is commonly agreed to be faster than python ruby perl. e.g. see

Why does elisp not have namespaces?

“Why does elisp not have namespaces?” answered by Artur Malabarba.

Emacs Controversy

The Emacs Cult

xah lee