Language Server Protocol (LSP) Kills Emacs

What is Language Server Protocol

The Language Server Protocol (LSP) is a protocol that lets programing language text editors and programing language parsers to talk to each other, so the editor can do things like syntax coloring, jumping to function's definition, etc, easily and correctly, without needing to write a parser for the language. (Language Server Protocol was originally developed for Microsoft's Visual Studio Code. Subsequently, in 2016, it is released as a general purpose project and open source.) [2017-05-05 https://github.com/Microsoft/language-server-protocol ]

Grow Emacs Lisp, Not External Tools

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 external tools. (this is already happening in lots packages.)

This dilutes emacs uniqueness.

The more critical thing is for progress of emacs lisp.

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 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?

There are a significant number of emacs lisp hackers that write compilers. Emacs lisp needs a lot improvements. If emacs lisp becomes better, they'd create programing language parsers in elisp overnight that is possibly better than the LSP server software.

here's a list of notable elisp programers who has written compilers or parsers:

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

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

• Phil Hagelberg [https://technomancy.us/] (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 [http://www.iro.umontreal.ca/~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 [http://newartisans.com/] , current emacs maintainer, and haskell/coq hacker, who works on IDE/compiler or such in C++ for some 20 years.

• Steve Yegge https://steve-yegge.medium.com/ , 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...

• emacs flycheck author [https://twitter.com/lunaryorn] is also a serious elisp hacker. Flycheck is a big project, connecting to all the other external tools and parsers.

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.
 ;; http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01006.html

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.

Stefan

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

• “s” → “The long lost Emacs string manipulation library.”. Rank 1. Has 500k downloads.
• “dash” → “A modern list library for Emacs.” Rank 4. Has 378k downloads. [see Emacs, Why You Should Not Use the Package Dash (2020)]
• “f” → “Modern API for working with files and directories.” Rank 18. Has 260k downloads.

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”, example: 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 ELisp: Trim String]

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

ELisp is 10 times slower than JavaScript?

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 https://github.com/xahlee/xah-find

perl and python. (the perl one is 20 years old, python is 10) https://github.com/xahlee/xah_find_replace

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

http://benchmarksgame.alioth.debian.org/

i'd be interested in result too.

by the way, JavaScript is commonly agreed to be faster than python ruby perl. e.g. see https://julialang.org/benchmarks/

Why does elisp not have namespaces?

“Why does elisp not have namespaces?” answered by Artur Malabarba. https://emacs.stackexchange.com/questions/2706/why-does-elisp-not-have-namespaces