> 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.
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.
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.
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 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]
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?
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.
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".
> 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!
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.
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?
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 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?
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.
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.
So the Emacs OS has a terminal? This means I can finally run vim in it.
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)