Emacs-libgterm: Terminal emulator for Emacs using libghostty-vt | Hacker News Reader

Emacs-libgterm: Terminal emulator for Emacs using libghostty-vt

github.com

92 pointssigna1132 comments

> Status: Early prototype. Fully vibe coded. [...]

Cool project... However, the terminal is where you enter passwords, ssh, set API keys etc. Something so sensitive should not be "Fully vibe coded".

For a project like this, I would expect to see a clarification which might read something like this: "Fully vibe coded, but I audited each and every line of generated code and I am already a domain expert in vt sequences and emacs so I know this program should be OK." But given that I did NOT see a clarification or statement like this, it becomes very difficult to trust a project like this.

Again, it is a cool idea.

The vast majority of your complaints are handled by libghostty-vt itself, not by this person's Emacs wrapper software over libghostty.

Ghostty is a great piece of software, with a stellar maintainer who has a very pragmatic and measured take on using AI to develop software.

Looking at the sophistication of modern security exploits, I'd say that just a few minor gaps, strategically positioned, can lead to surprisingly drastic results. Of course, Emacs is a niche editor/IDE/OS/whatnot, so an unlikely target, but still.

It's a great proof of concept though. In the meantime, I'll stick with vterm.

no malicious person is using emacs. the userbase is full of painfully honest people.

I hope they all secure their MELPA accounts properly, too!

(be-malicious) Debugger entered--Lisp error: (void-function be-malicious)

Yep, didn't work for me

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.

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.

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.

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.

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

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'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.

I wonder if I'll ever see the day when Emacs's several terminal implementations are unified. How nice would it be if one could use term.el with libvterm, libghostty etc. as a backend?

On another note, as a light terminal user, I've had great success with MisTTY. [1]

[1]: https://github.com/szermatt/mistty

I understand the need of terminal emulator for certain interactive programs, but inside Emacs I just use 'shell-command and output buffers. What's the benefit of having a terminal emulator inside the Emacs process? If the program is interactive (TUI) it won't integrate well with Emacs buffers/keybindings anyway right?

My main use case is emacsclient and vterm as a terminal multiplexer, in place of something like tmux or screen.

But even locally I use vterm. A terminal is just text, why wouldn't I manipulate it with emacs? At any time you can switch to `copy-mode` and it behaves like a read-only text buffer that you can manipulate as you please.

None really. And for most cases, the included term is more than enough.

I haven't tried this project, but did switch to vterm from shell-mode a while back because it managed to fix most of the paper cuts when using shell-mode. I also used to create a lot of custom compilation buffers for things b/c it would create links to files that were helpful, but that has been less helpful to me. At the end of the day, there were papercuts that made shell-mode and compilation buffers less ideal and most folks were focusing on traditional terminal support.

What do you know, wishes sometimes come true: https://news.ycombinator.com/item?id=45351060.

Wow, very cool indeed and i'd use it immediately if it was human-written.

How is evil mode support?

So the Emacs OS has a terminal? This means I can finally run vim in it.

It already has one, plus a native interface to whatever shell you prever (and its own because of course it does)

And then in vim you can spawn a shell to run ... oh, never mind.

Your snarky and condescending tone suggests that you perceive some kind of contest between Vim and Emacs for being a "superior" editor. I guess you have never discovered the fundamental truth - Emacs is not an editor, Emacs is a Lisp REPL with a built-in editor. It cannot be "better" or "worse" than Vim, in the same sense that a Swiss Army knife can't be inferior or superior to a scalpel. Vim is a brilliantly focused tool that does one thing with extraordinary precision and efficiency. Emacs is a programmable universe that, among other things, edits text. You're falling for the classic category error. Those who learn to master both are the truly disillusioned ones, maybe try to be like them, instead of chasing every opportunity to soothe your insecurities. There is a real, pragmatic world where both tools are equally used for true superior experience incomparable to any "alternatives".

Emacs had evil-mode (and terminal support) since forever.

In some cases eshell it's far better than sh, altough anything can be better than POSIX sh. Just try rc under 9front (or, as a demo, under GNU/Linux or OpenBSD). GNU tried to create a better interface to Unix with Emacs (and it shows) and 9front just went further throwing down all the legacy crap to the dust bin creating something better. No X, no ioctls, no sh, no Perl, no C++ (golang works, same people in the end).

I think Emacs today with the jitted Elisp interpreter it's able to do far more stuff than depending on external tools such as GNU coreutils, findutils and non-GNU Gnuplot. The 90% of these could be rewritten and even expanded and enhanced under Elisp running pretty fast and interfacing much better with Elisp than any other tool.

Ironically GNU on-current-unixes (and outside of Hurd) it's holding GNU and Emacs back, because a nonroot user can do far more stuff (without group permissions) under Hurd than in GNU/Linux. Think something like namespaces, remote mounting devices a la Rclone (and not just drives) and so on with a boosted Elisp interface and org-mode to manage far more stuff under you account than these restricted Unixen. But a paradigm change is needed.

The 9front users already got it, and the GNU Guix people just began doing that under Guile. Who knows, maybe in 15 years Emacs it's rewritten fully under a uber fast Guile with libre RISC-V microcode based CPU's from Taiwan or Estonia or whatever, loading Guile-optimized code on demand for HPC tasks and the like and some others loading a server-balanced microcode (and OS settings) grom a custom Guix config. That would yield a very different computing than the one we are suffering today. It would be the second Golden Age, similar to PDP10+ITS/WAIS creating the path for the literal 60 years of computing where basically Lisp and Forth invented everything or nearly everything.

> I think Emacs today with the jitted Elisp interpreter it's able to do far more stuff than depending on external tools such as GNU coreutils, findutils and non-GNU Gnuplot.

The problem with doing everything in Elisp is the lack of threading. GNU Find can search down multiple directories in parallel, and an Elisp implementation of Grep would block the Emacs UI while searching. Until Elisp gets threading it will fundamentally be limited to either short bursts of computation or frustrating UX because of blocking (see also frustrations with Gnus).

Emacs has had native threads (make-thread, thread-yield) since 26.1 (8 years ago), and async subprocess/process-filter patterns have existed even longer. The real issue is that Emacs threading is cooperative, not preemptive - but that's a different problem than "no threading". For IO-bound work like grep/find, make-process with async callbacks is the standard solution and it doesn't block the UI at all. consult--async-pipeline does exactly this.

The Gnus comparison is unfair because Gnus's UX problems were architectural (synchronous network IO designed before async patterns matured), not inherent to elisp itself. Modern packages don't make the same mistake.

The strongest remaining criticism is the cooperative threading model making it genuinely hard to do CPU-bound parallel work without external processes. That's real. But for the grep/find use case specifically - nobody blocks the UI on search anymore.

Reply on news.ycombinator.com