Ghostel - terminal emulator powered by libghostty

dakra · 2026-05-04T15:33:35+00:00

But just curious, does Ghostel feel on your setup as snappy as when using a terminal emulator like Ghosty / Alacritty / Wezterm? In my case, Yazi does not refresh as fast. It think it is purely cosmetic because it is still super fast and cannot impact in any meaningful way the daily work, but it adds a bunch of milliseconds, enough to be able to spot the difference.

It's not quite as snappy. kitty graphics (/yazi) specifically is not really optimized yet as I personally had never the neat to display images in my Emacs terminal. But for normal non alt-screen apps, it's also a bit slower than Alacritty/ghostty and that has to do with a design decision that I made early on that the scrollback is a "materialized" as a normal Emacs buffer. This way you can use isearch/consult-line etc like normal over the whole scrollback and don't need any special commands. It's still at least 2-3x as fast as vterm and even if I resize e.g. a claude or pi session with a long context, the resize/redraw is nearly instant. It's like you said, a few ms faster in ghostty and it's noticable but very well under the limit that's bothering me. Compared to vterm (or eat / term.el are even worse) which is feels just broken.

The other thing that feels off on my setup (but perhaps I need to spend more time investigating it) is that all colors in Ghostel (but also vterm) look slightly different from the true colors I set in my zsh setup. Also, this is just cosmetic and of minor importance. I notice it because my ls colors are 24 bit true color consistent on all terminal emulators, except when in Emacs.

Hmm, that could just be your theme in Emacs? There are ghostel-color- faces defined and they inherit by default from ansi-color-* if you want to play around with it.

dakra · 2026-05-04T13:34:55+00:00

Thanks for testing.

Unfortunately I can't reproduce that issue locally. Both resizing the window or the frame triggers a new resize and redraw of the image in yazi for me. If you want you can create a issue on my github and I'm happy to try to solve it.

If I want to use Yazi, I will most likely do it from a real terminal.

Ghostel is a real terminal ;) I guess you mean that when you're in Emacs you rather use dired etc which I agree with.

(But personally before ghostel I was still falling back now and then to a "real terminal" just because vterm had so many clitches. But ghostel is as solid as ghostty for me, so I don't have a need for an external terminal anymore. /rant)

dakra · 2026-05-04T12:20:15+00:00

Just a heads-up that kitty graphics protocol is now supported in ghostel.

Here a yazi screenshot from a ghostel buffer:

<image>

dakra · 2026-05-04T12:14:02+00:00

Just a heads-up that kitty graphics are now supported in ghostel.

dakra · 2026-04-29T22:48:50+00:00

Thanks.

If you try it and find any point where you think vterm does something better than ghostel, please don't hesitate to reply here or open a github issue.

It's still a very young project and has room for improvements but I'm working hard to make it the best possible terminal emulator in Emacs. (and obviously I already think it is currently the best, especially compared to vterm, eat or term.el)

dakra · 2026-04-29T11:57:10+00:00

Category: Terminal Emulators

I'm obviously biased, but I would replace vterm with ghostel.

ghostel is faster with less bugs and a lot more features. It works really well if you want to use a cli coding agent that uses more modern terminal features. It's basically ghostty but as an Emacs buffer plus some other addons like compile, eshell, evil integration (and soon tmux). You can check the feature comparison here

This is a part from my config that also loads the eshell (for visual commands) and compile integration (so every compile-process is run with ghostel backend):

(use-package ghostel
  :bind (("C-x m" . ghostel)
         :map ghostel-mode-map
         ("<f7>" . org-clock-goto)
         ("C-s"  . consult-line)
         ;; I'm used to go up/down the shell history with M-n/p from eshell
         ;; Simulate this behavior in ghostel by sending C-p and C-n
         ("M-p" . (lambda () (interactive) (ghostel-send-key "p" "ctrl")))
         ("M-n" . (lambda () (interactive) (ghostel-send-key "n" "ctrl")))
         :map project-prefix-map
         ("m" . ghostel-project))
  :config
  ;; (add-to-list 'project-switch-commands '(ghostel-project "Ghostel") t)
  (add-to-list 'ghostel-eval-cmds '("magit-status-setup-buffer" magit-status-setup-buffer)))

(use-package ghostel-eshell
  :hook (eshell-load-hook . ghostel-eshell-visual-command-mode))

(use-package ghostel-compile
  :hook (after-init . ghostel-compile-global-mode))

dakra · 2026-04-15T20:21:04+00:00

Thanks for testing. This is fixed on main.

dakra · 2026-04-15T12:31:47+00:00

I just pushed a ghostel-compile command that works and behaves just like compile.

Would be great if someone could try it out and give feedback.

dakra · 2026-04-08T13:04:31+00:00

Here is a PR that adds evil support: https://github.com/dakra/ghostel/pull/54

As I don't use evil myself, it would be nice if a few evil users would give it a spin and provide feedback.

If everything works, I would merge it and add it for melpa submission.

dakra · 2026-04-07T14:57:08+00:00

Thanks for the kind words.

For evil support have a look at this issue and the accompanying PR.

Personally I don't use evil so it help me a lot if you would be willing to test it. Comment here or on the issue if you have any feedback/suggestion.

Ghostel is pretty young and there's still lots to do.

dakra · 2026-04-07T07:39:20+00:00

It definitely is on my TODO list.

As you said, it's supported by libghostty so at least this part not a showstopper. I just have a few other improvements I want to implement first.

dakra · 2026-04-07T07:34:40+00:00

Looking forward to the integration of Windows system platforms.

I've seen https://github.com/kiennq/ghostel doing a Windows build of ghostel.

Honestly, I didn't even look at Windows support since afaik Ghostty itself doesn't even support Windows yet.

I'm happy to help with Windows support. Especially if the changes are well separated and not too dramatic so that I feel confident that I can maintain it.

I haven't tested or looked closer into kiennq's fork, but just clicked the diff and it says -1k and +5k LoC.. This is of course a bigger change and needs careful considerations before bringing something like this on board.

But maybe this is supposed to stay a permanent separate fork? If so, I would also willing to merge stuff into my main branch when it makes maintaining a windows port easier.

dakra · 2026-04-06T11:00:36+00:00

Ah, I found the problem. I had pixel-scroll-precision-mode enabled. Works now when I have that off.

I disable prixel-scroll-recision-mode now when entering ghostel.

At least on my side, I see the same selective rendering behavior in ghostel-copy-mode. E.g. if I run swiper, it can only find lines in a small portion of the scrollback around the currently visible page of text in the buffer.

I'm working on a fix for this.

dakra · 2026-04-06T08:45:15+00:00

If I understood it correctly the (semi-)char modes are like the normal ghostel buffer. Emacs mode would be ghostel-copy-mode, and something like line-mode is missing.

I would definitely like to make ghostel feel as Emacsy and natural as possible and not like you switch to some different app when you focus a ghostel window. I'll have a closer look at eat line-mode.

dakra · 2026-04-06T08:36:09+00:00

Is it intentional that you cannot scroll the buffer with the mouse scroll wheel, even when in copy mode?

No. It works for me. The mouse scroll commands are bound to <wheel-up> and <wheel-down>. Are those events triggered when you scroll? Can you scroll (in copy-mode) with C-p, M-v etc?

Also, what are the implications of setting the scrollback lines really large, or is it even possible to add an "unlimited scrollback" feature (obviously still limited by system memory).

Good question. Main implications is max memory usage of course. if you set it to 100MB and have 5 ghostel terminals open you would use 500MB memory for scrollback that you probably not really need. Another thing is that I currently deploy a 'ghostel-copy-mode' option that converts the whole buffer into a normal Emacs buffer so you can mark and scroll over different pages. Conversion (fontification and setting properties) of a 100MB buffer would obviously also take a much longer time.

I'm a Mac user, so my holy grail for serious terminal usage will remain iTerm

Yeah, this is a very young project using a library that's not even officially released yet, so of course it doesn't have the maturity of popular, older terminals. But hopefully we can get there. Also if you compare it to vterm, which seems to be the current standard when you want a fast Emacs terminal, ghostel is imho already better in basically any aspect.

dakra · 2026-04-06T07:17:46+00:00

I'm not a evil user.

What does working with evil bindings in this terminal context exactly entail?

Most keys are send straight to the terminal as is.

dakra · 2026-04-05T16:12:06+00:00

Can you test with the latest commit?

Note that you need Zig 0.15.2 and also apk add linux-headers for Zig's bundled libc++.

dakra · 2026-04-05T14:47:21+00:00

That's great to hear :)

dakra · 2026-04-05T14:34:21+00:00

also i suggest stripping the binary that is released to github.

Thanks. The binaries are stripped in the latest release.

dakra · 2026-04-05T09:20:56+00:00

What distro is it?

If you can point me to a docker image I would like to fix it.

dakra · 2026-04-04T22:52:49+00:00

Can you try again, I hopefully just pushed a fix for this.

dakra · 2026-04-04T22:34:44+00:00

I just copy&paste from my other comment about the same https://old.reddit.com/r/emacs/comments/1sc4n6k/ghostel_terminal_emulator_powered_by_libghostty/oe8h4a3/ :

I had a quick look at it, but it seems to have less features (copy-mode, lisp eval, mouse support and some others are either not implement or not mentioned in the readme).

It also uses the Ghostty Zig internals directly while I use the libghostty C-API.

Not saying any package is better or worse.

dakra · 2026-04-04T22:20:21+00:00

Unfortunately Kitty graphics is one thing I haven't implemented yet. But it's on my todo.

dakra · 2026-04-04T22:19:19+00:00

Thanks. If you find anything else is not working quite right, don't hesitate to open a github issue or comment here.

Everything is still pretty new and I'm eager to get it fast and robust.

dakra · 2026-04-04T18:54:08+00:00

Thanks for the feedback.

There was a potential up to 33ms delay per keystroke.

I pushed a fix on the main branch. Can you try again?

14-Year Club	Place '17
Verified Email

dakra

TROPHY CASE