2e0byo/emacs-ng

A new approach to Emacs - Including TypeScript, Threading, Async I/O, and WebRender.

emacs-ng

A new approach to Emacs

---

homepage • Deno/Javascript • webrender • ng-module • handbook • faq

---

Intro

emacs-ng is based off of the master branch of emacs, and regularly merges in the latest changes (this branch includes the native compilation feature from Andrea Corallo).

The last merged commit is 6ebe8b03d8 (Aug 24 2021).

Motivation

The goal of this fork is to explore new development approaches. To accomplish this, we aim to maintain an inclusive and innovative environment. The project is not about replacing elisp with a more popular language like Javascript. We just want to make emacs more approachable for people who don't like lisp as much as we do.

Contributions are welcome from anyone and we are always happy to invite new people to the project. We are open towards interesting ideas to make emacs better.

Why Emacs-ng

This project should be considered an additive native layer over emacs, bringing features like Deno's Javascript and Async I/O environment, Mozilla's Webrender, and other features in development. emacs-ng's approach is to utilize multiple new development approaches and tools to bring Emacs to the next level. It is maintained by a team that loves Emacs and everything it stands for - being totally introspectable, with a fully customizable and free development environment. We want Emacs to be a editor 40+ years from now that has the flexibility and design to keep up with progressive technology.

Contributing

Emacs combined with the rust ecosystem brings a lot of possibilities. If you have any idea for a new feature, just open an issue before starting work so we can give you some feedback.

We try to maintain a list of "new contributor" friendly issues tagged with "good first issue". You should also take a look at our handbook.

Features

Webrender

WebRender is a GPU-based 2D rendering engine written in Rust from Mozilla. Firefox, the research web browser Servo, and other GUI frameworks draw with it. emacs-ng use it as a new experimental graphic backend to leverage GPU hardware.

Dynamic modules

Allow dynamic modules to access more of Emacs's internals. Dynamic modules can be written to take advantage of these extra functionalities when they are available, while at the same time being fully compatible with vanilla Emacs.

Deno/Javascript

One of emacs-ng's primary features is integrating the Deno Runtime, which allows execution of JavaScript and Typescript within Emacs. The details of that feature are listed below, however many users would ask themselves WHY JAVASCRIPT? JavaScript is an extremely dynamic language that allows for a user to inspect and control their scripting environment. The key to note is that bringing in Deno isn't JUST JavaScript - it's an ecosystem of powerful tools and approaches that Emacs just doesn't have currently.

• TypeScript offers an extremely flexible typing system, that allows to user to have compile time control of their scripting, with the flexibility of types "getting out of the way" when not needed.
• Deno uses Google's v8 JavaScript engine, which features an extremely powerful JIT and world-class garbage collector.
• Usage of modern Async I/O utilizing Rust's Tokio library.
• Emacs-ng has WebWorker support, meaning that multiple JavaScript engines can be running in parallel within the editor. The only restriction is that only the 'main' JS Engine can directly call lisp functions.
• Emacs-ng also has WebAssembly support - compile your C module as WebAsm and distribute it to the world. Don't worry about packaging shared libraries or changing module interfaces, everything can be handled and customized by you the user, at the scripting layer. No need to be dependent on native implementation details.

Performance

v8's world-class JIT offers the potential for large performance gains. Async I/O from Deno, WebWorkers, and WebAsm, gives you the tools to make Emacs a smoother and faster experience without having to install additional tools to launch as background processes or worry about shared library versions.

Package management

use-package and straight are really great so we decided to make them built-in packages. But since we don't want to break configs, this is an optional feature.

Just put this line into your ~/.emacs.d/early-init.el:

(setq ng-straight-bootstrap-at-startup t)

emacs-ng's Issues

Emacs erroneously has super set when switching to a window.

s-<x> is undefined; continues until you C-g, which shows C-s-g is undefined.

In general modifier handling is currently poor, e.g. C-x C-c too quickly is read as C-x c. Investigate moving the modifier handler to rust and using logical key, or tuning the modifier press/release loop.

Tracking

This fork is currently far from ready, but working locally.

Known bugs:

• Resize handler is not called promptly on window resize. Indeed I can't figure out what listens to resized event at all. We probably need to register a handler. The result is that Emacs becomes unresponsive after a resize for 0 <= t < \infinity. Forcing an internal redisplay by e.g. M-x (loads helm) and then sending another resize event (resizing the window twice) tends to work. [fixed with new rendering logic]
• Overlay windows aren't displayed properly, so they tile. They're also useless until scaled properly. This makes lsp-lens annoying, although I still use it by manually resizing the lens window and waiting for it to behave itself
• Segfaults on message-box. (Probably a problem in upstream, but def. to fix.)
• Unable to load fonts from elisp/at runtime.
• Lsp right-margin text wraps onto new line. I think upgrading emacs itself will fix this. [fixed: probably due to scaling]
• Something byte-compiled causes periodic errors. Again, I think a problem with emacs. [gone]
• The xpm hack works, but for some reason doesn't resize images. Should they be scaled like fonts? But others work fine.
• Occasional segfault which I've not tracked down (need to build emacs with debugging I think).
• Automatic composite glyphs not implemented yet---we just return none rather than crashing. [Work started] [fixed upstream]
• Some of the panic()s are reachable. Slowly removing them.
  - [ ] No menu bars (true in emacs-ng in general). I don't use them, but. [problem with window toolkit]
• LSP breadcrumbs display same size as rest of buffer. I actually quite like this and am not sure if it's a bug, but def. wasn't the case with native emacs before. [fixed with new scaling code]
• Not all input works correctly. Number-pad enter sends m not ^m. [Easy to debug---just print the keyboard events] [fixed]

get custom colour symbols from image lisp object

https://www.gnu.org/software/emacs/manual/html_node/elisp/XPM-Images.html

This is doubtless where things like 'opaque' are set.

High gpu memory usage

With only one window open we use around 1GB, which feels a tad high. Allocation happens as soon as we start, i.e. it's not a memory leak.

Compose key does not work.