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.

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

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.

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.

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

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

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