Item — HN Reader

I love to see new Emacs Lisp projects, BUT: personally I prefer a simple ‘pure Emacs standard library’ experience as much as possible. I have been using Emacs over 40 years and this return to simplicity is a new thing for me.

I used to have a Xerox Lisp Machine in the 1980s and dreamed to have Emacs be the ‘catch all’ environment like a Lisp Machine. Now I mostly just use Emacs to edit code.

3 comments

You might be sort of interested in the Emulate-A-Terminal (EAT) package: https://codeberg.org/akib/emacs-eat which provides a very fast terminal emulator entirely in emacs lisp.

I use eat. So far it’s been the best one. But I did have to fix a few bugs, and add kkp support to it. It’s not the fastest but it gets the job done.

What did you need to fix! And what did you need KKP for? are you running emacs in eat?

Do you have any of your fixes publicly available?

Check PR requests on its website and we will find many bug fixes. Unfortunately its owner is busy with other things and can't merge them.

My favorite part about EAT is the fact that it works in-buffer in Eshell, so I don't need a separate buffer for visual commands.

I am partial to your sentiment but I don't think writing all the terminal handling code in elisp gives us code that might be too interesting to read (to me at least).

Understanding the VT state machine and all its quirks and inconsistencies is not high up in my list of code I'd like to learn. It is good it is packaged up in a library and emacs is just a consumer of it.

libghostty will have excellent compatibility and features rather than an elisp implementation that maybe half baked.

I stopped living in the world of turtles all the way down. Now I'm more like, hey is this is good library ? Is it integrated well ? It does not matter if it is in zig, rust, c++, lisp, scheme, ...

Jitted Elisp for itself has much more power because of function composability than badly reusing libraries without even a common API like OLE/COM under Windows. You are just creating silos badly interopearting together.

Even 9front has something like 9p, namespaces and everything it's truly a file. Even GNU/Emacs under Hurd doesn't have its full power developed until the GNU people ditch Gnuplot for their own GNU-born capable 3D plotutils and the like.

And today given the speed of jitted Emacs if I were the Calc maintainer I'd try to write a PNG/farfbled (or whatever it's called) plotting tool in pure Elisp, with both TTY and graphical outputs.

Depending on non-GNU, external tools it's holding GNU and Elisp back.

I'd use Emacs if they:

- Purged are gnuplot dependencies with a custom and actual GNU bound 3d plotting software. GNU calc for Emacs should have been working with core Emacs libraries long ago.

- Plotutils extended for 3D should have been mandatory long ago

- GNU made Texinfo not be Texlive dependant for PDF/HTML output. Texinfo should have been standalone a la mandoc it's under Unix for PDF output.

> I'd use Emacs if they:

This is a bit of a wishlist without much grounding in how these tools actually work.

Emacs doesn't "depend" on gnuplot in any meaningful sense. org-babel can use it, but it's optional. The request for "custom and actual GNU bound 3d plotting software" is vague to the point of being meaningless. What would that even be? Gnuplot is already GNU-adjacent and works fine.

calc.el is already bundled with Emacs and has been for decades. It doesn't need gnuplot at all for its core functionality. You want 3D plotting integrated with calc or something? You can just build one - elisp is not that hard, LLMs these days understand it better than some other, traditional PLs.

Plotutils - is an obscure GNU package that's largely unmaintained. Advocating for it as a "mandatory" dependency in 2026 is puzzling. The project is essentially dead upstream.

Last thing is Texinfo project problem, not really an Emacs one.

You seem to have a bunch of opinions about GNU software purity rather than someone who has hit concrete practical blocks. Emacs is for pragmatists - you either solve a problem on the spot (without complaining about the purity of the solution); ask if someone done that already and use an existing package; or just put a TODO note in a .org file and deal with that later.