I think the thing that stops me from running more processes inside emacs is that a large diff parse from magit or similar can block everything, and so I end up keeping a separate terminal around anyway.

Howdy,

Awesome project. Been using with doom for a while. How do you manage to get scrolling programs to work (eg Lazygit or Reasonix) where other emulators fail? Is it something special in your implentation or library that makes this work?

Hi dakra!

> is there something Ghostel is missing

eshell allows me to manipulate text as I would in any other Emacs buffer. If I have a function which wraps a word in quotes, and bind it to a key, I can be confident it will work in eshell like it does anywhere else. It's a real killer feature. If I use evil-mode, or xah-fly-keys, or simply want to use ispell to correct the spelling of a word, it all works.

Unfortunately with Ghostel none of this works. It's not integrated in the same way. There are extensions like evil-ghostel-mode, but they are limited.

Are there any plans to improve this, or is it a limitation Ghostel has to live with?

A Ghostel equivalent of eat-eshell-mode would be amazing.

How was integration for you guys? Was the integration easier for you guys since you have an established emacs system consuming terminal output with reasoned semantics over what goes where for existing subsystems (rendering, osc codes, etc)?

For libghostty-vt, since you're targeting a terminal TUI instead of an external subsystem (for example; for ghostty, you hit libghostty-vt -> GPU rendering, which is external), you still have to buy into terminal semantics. in my experience, since I was trying to replicate mosh with libghostty-vt as the parser, what happened was that my optimized re-rendering kept getting increasingly coupled to terminal semantics (and the UDP state update model too), otherwise I'd have to send the entire terminal grid over the network like, every time.

What are the tricks for making this both performant and not like, utter cancer? You have a harder issue here too (similar to tmux) in that certain optimizations are just not available to you, or you have to translate (literally geometrically) certain instructions

I agree.

And I would also prefer if the link went to https://github.com/dakra/ghostel instead of the documentation which is not that helpful if you don't know what the project is.

.el = emacslisp file extension

Ghostel co-maintainer here: Understand if you don't have a repro, but if you ever have something actionable we'd love it if you filed an issue, or have the information get to us some other way.

The junk at the top of the screen sounds like it could be https://github.com/dakra/ghostel/issues/495 and it should be fixed on later versions. But maybe you're seeing another bug. The tricky part is replicating the libghostty-vt internal data into an Emacs buffer while only replacing the parts that need to be replaced. We have property based tests to exercise this a lot, but sometimes things slip through.

The latest released version as I'm writing this should have improved lifecycle handling, so maybe it also fixes some of your issues.

As you say, the project is still in the early phase so hopefully, we can iron things out over time.

I am running Ghostty 1.1.3, on Gentoo Linux.

I have opened right now about a dozen Ghostty windows and about 20 tabs in each window, i.e. more than 100 shell instances.

I have started in as many of them as I could, before becoming too bored, a "ls -lR" on a file system with many millions of files.

I could not see any problem, much less any crash. I have been using Ghostty for a few months, very intensively, all day long, and I have not seen any crash or other suspicious behavior.

If you have seen a crash, perhaps there was either some specific version of Ghosstty that had a bug, or, more likely, some weird interaction with some other software that you have, and which might be buggy, e.g. the GPU driver. (I am using an NVIDIA GPU.)

cool story bro. feel free to make a github issue. I've been daily-driving Ghostty for years and i don't remember the last time it crashed on me.

Exactly as you say, the greatest difference with the recent generation of video terminal emulators that use the GPU through OpenGL or the like, is the much greater rendering speed, which becomes very noticeable with millions of lines of scrolling text, especially if you use high-resolution monitors.

Unfortunately, millions of lines of scrolling text are no longer unusual, especially when you frequently compile big software projects. The use of high-resolution monitors has also been normal for many years.

Instant window rendering is addictive, so now I would never return from a fast terminal emulator like ghostty to an older video terminal emulator. The last terminal emulator that I had been using before ghostty was kitty, which was also pretty fast in comparison with traditional terminal emulators, but I like ghostty more.

Honestly not sure. I used ghosty and others for awhile but had continuous issues of it not passing a compatible term variable so a lot of tuis would break.

That's because MELPA (and ELPA) doesn't have a way to attach platform specific files. It's all just git checkouts.

That means we would have to check in the module binary for all platforms (>10MB together) if we want that it comes with the distribution.

Also looking at e.g. jinx, another popular package that uses Emacs native modules, it does it like vterm and offers to compile on first usage.

So as a Emacs package author, for a user friendly installation you can realistically only offer to download or compile on first use.