> 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.
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 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.
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]
> 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.
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.
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 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?
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.
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.
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
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.
It already has one, plus a native interface to whatever shell you prever (and its own because of course it does)