Hacker News Reader

Comment by Zambyte | Hacker News Reader

I dream of combining wlroots and GNU Guile to make a graphic-first and multi-threaded by default Emacsen that does not aim to be source compatible with Emacs Lisp.

View on HN

Why wlroots? Isn't it better to target an abstraction api over the various GPU libraries (vulkan, metal etc)?

And I would have asked about Guile too but that is another matter.

I think LEM's approach is better here in utilizing SDL and common lisp. If they write an ELisp interpreter and somehow translate Emacs editor api so plugins would work in LEM too, that would be ideal.

Lem is cool and is shipping features fast. We don't have an Elisp interpreter, but we already have a small Magit-like interface: see changes, stash files and hunks (no line precision yet), interactive rebase…

https://lem-project.github.io/usage/usage/

(development notes: https://lisp-journey.gitlab.io/blog/oh-no-i-started-a-magit-...)

Lem has:

- syntax highlighting and language-specific commands (linter etc) for many languages: Common Lisp of course, but also Python, Rust, C, Erlang… JSON, HTML, markdown (including interactive preview in a browser)… a directory mode…

  - LSP should just work

  - treesitter is a WIP

- graphical and terminal interfaces

- integrated terminal (libvterm)

- project-related commands, interactive grep, tabs, a side-bar project explorer, keyboard macros, multiple cursors, built-in help (to a certain extent), mouse support, transparent background…

Interesting. Is Lem the editor you use most for editing code?

For editing text that is not code?

wlroots because I have little experience with GPU things, and they have already done a lot of the heavy lifting that I would do. I specifically want it to be a window manager, so it can script graphical applications in the same way that GNU Emacs can script text applications.

Regarding Guile - I am familiar with it since I use GNU Guix. I think it is one of the more practical Scheme implementations with its current ecosystem.

Also on Guile - it is meant to be embedded in C programs (like wlroots). It is one of the best options in that domain of Scheme implementations.

Guile is the GNU extension language. Seems like the best candidate for an emacs replacement.

There was already a project to port emacs to run on guile. Guile supports both emacs lisp and scheme for this reason. The project seems to have run out of steam but it was mostly working at one point AFAIK.

Well, an Emacsen that hopes achieving the same degree of popularity as Emacs should be usable in Windows too. Last I checked, Guile had problems in Windows...

I wouldn’t consider running directly on Windows a hard requirement. You can run it under WSL[1|2] for instance, or bundle a very minimal WSL distribution that only runs your software.

It would also simplify the codebase, to scrap the native Windows support and outsource that responsibility to WSL.

Many have tried, but few have succeeded at creating an Emacs-replacement.

Good luck!

I would say, that with Enrich Gamma at the steering wheel, and Microsoft's money, VSCode is succeeding pretty well.

I'd think that VSCode eats into the 'market share' of Eclipse and the like, but I can't see it as replacement for Emacs at all.

Better look at the shape of Emacs market share evolution since VSCode exists.

Turns out JavaScript is more appealing than Elisp, plus the graphical capabilities of having a browser engine.

VS Code is nothing like emacs at all except in the most basic sense that they’re both text editors popular with programmers.

I am old enough to have used XEmacs when the paint was still drying.

On similar lines I've wondered about reimplementing the C parts of Emacs in Common Lisp. At that point Elisp would be a hosted language, letting you benefit from all the existing packages.

Lem is an Emacs using CL (also instead of Emacs Lisp): https://lem-project.github.io/

I haven’t looked at lem in a while. I need to though. It and Nyxt are both really cool.

Giving up the Elisp ecosystem will be hard though.

It is also graphical, and multi-threaded!

That was the goal of CEDAR: https://gitlab.com/sasanidas/cedar (staled, too big of a project). But yeah, Lem!

> that does not aim to be source compatible with Emacs Lisp.

But then who would use it?

Reply on news.ycombinator.com