Role of Lisp in Emacs-NG?

[TinaRussell]

This is a request for clarification. I’m new to this project; does/will Emacs-NG allow me to extend its functionality via Lisp, with all that Lisp entails (i.e. code is data, functions can be advised, hooks everywhere, programmatic macros), or is Lisp going by the wayside for a JavaScript-centric environment? I know that Emacs’s implementation of Lisp is far, far from perfect (see my comment here), but switching to JavaScript, pidgin tongue of the cube farm, has such a “you were supposed to defeat the Sith, not join them!” vibe to me. Will Emacs-NG give me the power of Lisp with the features of JavaScript, or will Lispers like me feel like second-class citizens? (see also #78)

[brotzeit]

I'm starting to think that we should make it more clear that this project is not about javascript. This was just one idea that's supposed to allow making things faster and to make emacs more appealing to users that don't like lisp as much as we do. It's definitely not about replacing lisp with javascript or about becoming javascript-centric.

The goal of this project is to explore new ideas and to give emacs contributors more flexibility. I would love to see a modern lisp instead of elisp.

[black7375]

https://www.emacswiki.org/emacs/CategoryExtensionLanguage

There have been several attempts to use extended languages ​​in Emacs.(ecaml, Pymacs, Emacs EPL, haskell-emacs, ...) But no one says it can replaces elisp. I do not think this project is a replacement for elisp, although it is a bit more integrated. I hope that it makes the influx of newbies easier, provides better performance, features, and expandability, and makes more people use Emacs.

As written above, this project is not just for JS extension. There may be features that are difficult to upstream due to license, etc. Webrender and the recent PR, #192, can be a direct example. Other than that, my thoughts are written here. https://github.com/emacs-ng/emacs-ng/issues/187#issuecomment-803266703

[DavidDeSimone]

To echo what the other core contributors have said, our goal is not to replace elisp. Our team is filled with members who have written a lot of elisp (and lisp in general), and love everything that lisp languages bring to the table. We want emacs-ng to add to your emacs experience, not take anything away from it. Adding JavaScript and TypeScript as peer languages just opens more options for users. Learning emacs as a brand new programmer can be daunting because you have to learn a. elisp and b. the emacs API for interacting with the editor. If we can reduce that so they only have to learn the API (assuming a lot of new developers know basic JS), I think we can make learning emacs more approachable. Once they know the API, they might have an easier time learning elisp, since they can translate their JS code into elisp, and that can be a gateway to other lisps.

This is a good thread to mention my personal history of the project for background. As many people have noticed, this project is actually a fork of remacs, which was the result reimplementation of emacs. I was an early contributor to that project, but due to personal issues I wasn't involved in open source programming for a couple years. Last fall I returned to open source programming and was approached by the core contributors if I was interested in contributing to a new project they were developing - exploring new development approaches in emacs. The first major feature was harryfei's webrender, which started as a PR to remacs. My emacs-ng fork is still named emacs-webrender and I have no intention on changing it. I started by fixing some minor bugs in the LispSubr implementation and our proc majors. From there, I had grown very familiar with the low level internals of emacs due to some of the projects I had taken on back in the day (I still have my RFC for starting to rewrite the lisp GC in Rust, https://gist.github.com/DavidDeSimone/400e0f6041d2f4a1eb7938f113a6036f)

Once I joined the project, with the general direction of "don't rewrite, add cool new stuff", I started to work down my list of major things I wanted to add to remacs a few years ago.

1. Rewrite unexec (beaten by the fantastic pdumper code)
2. Add a JIT/Native Compilation (beaten by Andrea).
3. Make emacs have better async functionality
4. Add v8 to emacs

I started on # 3 by adding some primitives to be used for jsonrpc. Everything in ng_async .rs is targeted with that in mind. It was a fun little project, and once I knocked that out, I was looking for something new to do. @yyoncho suggested that we try integrating Deno into emacs, which I decided to take on, since I could get a two for one and knock out 3 and 4. It was shockingly easy, though I do have a lot of experience embedding JavaScript VMs into applications. Version 1 was very basic compared to what we have now - the initial PR didn't even have TypeScript support. We announced and got VERY mixed reviews. I think most people thought we were an April Fools Joke made in late December, or they just assumed that our code didn't actually work. Others just didn't "get it" - I would give them code examples and they just couldn't believe what I was claiming. As soon as anyone heard "JavaScript", people thought they we must all be hipster web devs that wanted to rewrite emacs in React or some nonsense. Honestly I don't think that stereotype fits any core member, most are pretty salty emacs veterans.

Since that time we have fleshed out our Deno support much much more, and have added some additional awesome things, and have more coming down the pipe. There is a reason that the first thing we mention in our README is our "Motivation", because that motivation is really the core of the project - to add cool things to emacs and make it better by exploring new development approaches.

[TinaRussell]

I'm glad I asked this question! These are great responses 😊