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

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 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?

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

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

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

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.

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

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.

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

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

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.

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.

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)

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

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

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

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

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

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?

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?

emacs-libgterm

Terminal emulator for Emacs built on libghostty-vt, the terminal emulation library from the Ghostty terminal emulator.

This project follows the same architecture as emacs-libvterm but uses Ghostty's terminal engine, which offers:

SIMD-optimized VT escape sequence parsing
Better Unicode and grapheme cluster support
Text reflow on resize
Kitty graphics protocol support
Active development and maintenance

Status: Early prototype. Fully vibe coded. Only tested on macOS (Apple Silicon). Terminal works with ANSI colors, full key handling, scrollback, cursor sync, and drag-and-drop. Some character width mismatches with Powerline/NerdFont glyphs remain. Here be dragons.

Requirements

Emacs 25.1+ compiled with --with-modules (dynamic module support)
Zig 0.15.2+ (install via asdf install zig 0.15.2 or ziglang.org)
Git (to clone the Ghostty source)

Installation

use-package + straight.el (recommended)

(use-package gterm
  :straight (:host github :repo "rwc9u/emacs-libgterm" :files ("*"))
  :init
  (setq gterm-always-compile-module t))

Note: The :files ("*") is required so straight.el copies the Zig source files and build system, not just .el files.

use-package + vc (Emacs 30+)

(use-package gterm
  :vc (:url "https://github.com/rwc9u/emacs-libgterm" :branch "main")
  :init
  (setq gterm-always-compile-module t))

Note: use-package :vc copies all files by default, so no extra :files configuration is needed.

use-package + quelpa

(use-package gterm
  :quelpa (gterm :fetcher github :repo "rwc9u/emacs-libgterm" :files ("*"))
  :init
  (setq gterm-always-compile-module t))

use-package + local clone

(use-package gterm
  :load-path "/path/to/emacs-libgterm"
  :init
  (setq gterm-always-compile-module t))

Manual

(add-to-list 'load-path "/path/to/emacs-libgterm")
(require 'gterm)

Then M-x gterm to open a terminal.

What happens on first load

gterm detects the missing compiled module
Automatically clones Ghostty into vendor/ghostty (if not present)
Applies a build patch for macOS compatibility (if needed)
Compiles the Zig dynamic module via zig build
Loads the module

The only prerequisite is having Zig and Git installed. Set gterm-always-compile-module to t to skip the confirmation prompt, or leave it nil to be asked first.

Manual build (optional)

If you prefer to build manually:

git clone https://github.com/rwc9u/emacs-libgterm.git
cd emacs-libgterm
zig build
zig build test  # run tests

Ghostty will be cloned automatically by zig build if not present, or you can clone it yourself:

git clone --depth 1 https://github.com/ghostty-org/ghostty.git vendor/ghostty

Usage

Key	Action
`M-x gterm`	Open a new terminal
Arrow keys	Navigate / command history
`C-y` / `Cmd-V`	Paste from kill ring
`C-c C-k`	Enter copy mode (select text, `y` to copy, `q` to exit)
`Shift-PageUp/Down`	Scroll through history (page)
Mouse wheel / Trackpad	Scroll through history (5 lines)
`C-c C-v`	Snap back to live terminal
`C-c C-c`	Send Ctrl-C to shell
`C-c C-d`	Send Ctrl-D (EOF) to shell
`C-c C-z`	Send Ctrl-Z (suspend) to shell
Drag file from Finder	Send file path to terminal

Build Options

# Specify custom Emacs include path (for emacs-module.h)
zig build -Demacs-include=/path/to/emacs/include

# Build with optimizations
zig build -Doptimize=ReleaseFast

Architecture

+----------------+     +---------------------+     +---------------+
|  gterm.el      |---->|  gterm-module.so    |---->|  ghostty-vt   |
|  (Elisp)       |     |  (Zig -> C ABI)     |     |  (Zig lib)    |
|                |     |                     |     |               |
| - PTY mgmt     |     | - Terminal create   |     | - VT parse    |
| - Keybinds     |     | - Feed bytes        |     | - Screen      |
| - Display      |     | - Styled render     |     | - Cursor      |
| - Copy/Paste   |     | - Cursor track      |     | - Scrollback  |
| - Scrollback   |     | - Mode query        |     | - Reflow      |
+----------------+     +---------------------+     +---------------+

Customization

;; Change shell (default: /bin/zsh)
(setq gterm-shell "/bin/bash")

;; Change TERM variable (default: xterm-256color)
(setq gterm-term-environment-variable "xterm-256color")

;; Auto-compile without prompting
(setq gterm-always-compile-module t)

;; Mouse wheel scroll speed (default: 5 lines per event)
(setq gterm-mouse-scroll-lines 5)

Known Issues

Character width mismatches — some Unicode characters (Powerline glyphs, NerdFont icons) may render at different widths in Emacs vs the terminal, causing minor alignment issues with fancy prompts
No mouse support — programs like htop that use mouse events are not yet supported

License

GPL-3.0 (required for Emacs dynamic modules)

Hacker Times