> 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, ...
Jitted Elisp for itself has much more power because of function composability than badly reusing libraries without even a common API like OLE/COM under Windows. You are just creating silos badly interopearting together.
Even 9front has something like 9p, namespaces and everything it's truly a file. Even GNU/Emacs under Hurd doesn't have its full power developed until the GNU people ditch Gnuplot for their own GNU-born capable 3D plotutils and the like.
And today given the speed of jitted Emacs if I were the Calc maintainer I'd try to write a PNG/farfbled (or whatever it's called) plotting tool in pure Elisp, with both TTY and graphical outputs.
Depending on non-GNU, external tools it's holding GNU and Elisp back.
- Purged are gnuplot dependencies with a custom and actual GNU bound 3d plotting software. GNU calc for Emacs should have been working with core Emacs libraries long ago.
- Plotutils extended for 3D should have been mandatory long ago
- GNU made Texinfo not be Texlive dependant for PDF/HTML output.
Texinfo should have been standalone a la mandoc it's under Unix for PDF output.
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".
Emacs had evil-mode (and terminal support) since forever.
In some cases eshell it's far better than sh, altough anything can be better than POSIX sh. Just try rc under 9front (or, as a demo, under GNU/Linux or OpenBSD). GNU tried to create a better interface to Unix with Emacs (and it shows) and 9front just went further throwing down all the legacy crap to the dust bin creating something better. No X, no ioctls, no sh, no Perl, no C++ (golang works, same people in the end).
I think Emacs today with the jitted Elisp interpreter it's able to do far more stuff than depending on external tools such as GNU coreutils, findutils and non-GNU Gnuplot. The 90% of these could be rewritten and even expanded and enhanced under Elisp running pretty fast and interfacing much better with Elisp than any other tool.
Ironically GNU on-current-unixes (and outside of Hurd) it's holding GNU and Emacs back, because a nonroot user can do far more stuff (without group permissions) under Hurd than in GNU/Linux. Think something like namespaces, remote mounting devices a la Rclone (and not just drives) and so on with a boosted Elisp interface and org-mode to manage far more stuff under you account than these restricted Unixen. But a paradigm change is needed.
The 9front users already got it, and the GNU Guix people just began doing that under Guile. Who knows, maybe in 15 years Emacs it's rewritten fully under a uber fast Guile with libre RISC-V microcode based CPU's from Taiwan or Estonia or whatever, loading Guile-optimized code on demand for HPC tasks and the like and some others loading a server-balanced microcode (and OS settings) grom a custom Guix config. That would yield a very different computing than the one we are suffering today. It would be the second Golden Age, similar to PDP10+ITS/WAIS creating the path for the literal 60 years of computing where basically Lisp and Forth invented everything or nearly everything.
> I think Emacs today with the jitted Elisp interpreter it's able to do far more stuff than depending on external tools such as GNU coreutils, findutils and non-GNU Gnuplot.
The problem with doing everything in Elisp is the lack of threading. GNU Find can search down multiple directories in parallel, and an Elisp implementation of Grep would block the Emacs UI while searching. Until Elisp gets threading it will fundamentally be limited to either short bursts of computation or frustrating UX because of blocking (see also frustrations with Gnus).
> 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!
(be-malicious) Debugger entered--Lisp error: (void-function be-malicious)
Yep, didn't work for me
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.
My favorite part about EAT is the fact that it works in-buffer in Eshell, so I don't need a separate buffer for visual commands.
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?
Check PR requests on its website and we will find many bug fixes. Unfortunately its owner is busy with other things and can't merge them.
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, ...
Jitted Elisp for itself has much more power because of function composability than badly reusing libraries without even a common API like OLE/COM under Windows. You are just creating silos badly interopearting together.
Even 9front has something like 9p, namespaces and everything it's truly a file. Even GNU/Emacs under Hurd doesn't have its full power developed until the GNU people ditch Gnuplot for their own GNU-born capable 3D plotutils and the like.
And today given the speed of jitted Emacs if I were the Calc maintainer I'd try to write a PNG/farfbled (or whatever it's called) plotting tool in pure Elisp, with both TTY and graphical outputs.
Depending on non-GNU, external tools it's holding GNU and Elisp back.
I'd use Emacs if they:
- Purged are gnuplot dependencies with a custom and actual GNU bound 3d plotting software. GNU calc for Emacs should have been working with core Emacs libraries long ago.
- Plotutils extended for 3D should have been mandatory long ago
- GNU made Texinfo not be Texlive dependant for PDF/HTML output. Texinfo should have been standalone a la mandoc it's under Unix for PDF output.
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.
How is evil mode support?
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".
It already has one, plus a native interface to whatever shell you prever (and its own because of course it does)
And then in vim you can spawn a shell to run ... oh, never mind.
Emacs had evil-mode (and terminal support) since forever.
In some cases eshell it's far better than sh, altough anything can be better than POSIX sh. Just try rc under 9front (or, as a demo, under GNU/Linux or OpenBSD). GNU tried to create a better interface to Unix with Emacs (and it shows) and 9front just went further throwing down all the legacy crap to the dust bin creating something better. No X, no ioctls, no sh, no Perl, no C++ (golang works, same people in the end).
I think Emacs today with the jitted Elisp interpreter it's able to do far more stuff than depending on external tools such as GNU coreutils, findutils and non-GNU Gnuplot. The 90% of these could be rewritten and even expanded and enhanced under Elisp running pretty fast and interfacing much better with Elisp than any other tool.
Ironically GNU on-current-unixes (and outside of Hurd) it's holding GNU and Emacs back, because a nonroot user can do far more stuff (without group permissions) under Hurd than in GNU/Linux. Think something like namespaces, remote mounting devices a la Rclone (and not just drives) and so on with a boosted Elisp interface and org-mode to manage far more stuff under you account than these restricted Unixen. But a paradigm change is needed.
The 9front users already got it, and the GNU Guix people just began doing that under Guile. Who knows, maybe in 15 years Emacs it's rewritten fully under a uber fast Guile with libre RISC-V microcode based CPU's from Taiwan or Estonia or whatever, loading Guile-optimized code on demand for HPC tasks and the like and some others loading a server-balanced microcode (and OS settings) grom a custom Guix config. That would yield a very different computing than the one we are suffering today. It would be the second Golden Age, similar to PDP10+ITS/WAIS creating the path for the literal 60 years of computing where basically Lisp and Forth invented everything or nearly everything.
> I think Emacs today with the jitted Elisp interpreter it's able to do far more stuff than depending on external tools such as GNU coreutils, findutils and non-GNU Gnuplot.
The problem with doing everything in Elisp is the lack of threading. GNU Find can search down multiple directories in parallel, and an Elisp implementation of Grep would block the Emacs UI while searching. Until Elisp gets threading it will fundamentally be limited to either short bursts of computation or frustrating UX because of blocking (see also frustrations with Gnus).
Wow, very cool indeed and i'd use it immediately if it was human-written.