Ghostel.el: Terminal emulator powered by libghostty

It would be nice to have some practical examples of how efficiently use its different input modes. On the surface the reasoning is straightforward - a terminal wants every keystroke. The editor also wants keystrokes for its own commands. These two desires are irreconcilable, so any editor-embedded terminal must have a way to switch "who owns the keyboard." That switch is a mode. There is no escaping it.

But like people coming to Emacs from Neovim may get confused why is nvim +term has only two modes, but this one has 5, what's the point? Without clearly understanding the problem, the knee-jerk reaction might be "this thing is an over-engineered BS", while in truth Ghostel isn't more complex because it's over-engineered - it's more complex because it solves more of the problem - the extra modes are opt-in tools for tasks nvim simply doesn't address. But it's not super clear how in practice use that leverage efficently.

Yeah, Ghostel works great for me so far!

Two things: - defined f1 to toggle between semi-char vs copy modes - I ask myself "Is it ok if Emacs dies or I nuke it?" If not, then I execute a command in the normal terminal

Does ghostty have any features that makes it better than kitty in anyway? I keep seeing this all over the place, but I still don't understand why it's better than existing options.

Can someone help who's used both help me, what's the elevator pitch for this, why is it worth checking out?

This is just optional.

I explained why it's not in the package in https://news.ycombinator.com/item?id=48881722

For all Emacs package updates, it's best of course to check the source what's changed and then you can compile yourself.

PS, I also think Emacs is one of the few ecosystems where people actually check what changed. It's not like npm where you have a million of deps unreviewed pulled in.

Personally I use borg and always at least quick check what changed, and most Emacs package managers have a similar feature.

Having used it for three weeks before coming back to Kitty, my conclusions were that it’s a better terminal for people who need a terminal but don’t ‘live in’ their terminal. Ghostty just feels really polished and ‘native’ and it’s obviously faster than, say, iterm or the stock term on macOS. So Ghostty is what I would now recommend to anyone who just wants a nice terminal without the goal of turning it into a highly personalized IDE, like Kitty allows you to do.

The only feature of Ghostty that I now miss in Kitty: setting the text size of each window pane independently. Oh and the slightly smoother quake terminal, even though I don’t use that much.

Ghostty makes some choices that I personally find bizarre. For one, on macOS, cmd+, opens config in textedit instead of in $EDITOR. Another is there isn’t a key action for moving panes; you need to use the mouse. At least half of the config options are platform-specific. And weirdest of all scripting is limited and can only really be done with (get this) AppleScript.

So, like I surmised (and I could be wrong, of course), Ghostty is just a nice terminal that lives alongside your other apps; Kitty is powerful enough to practically act like a second desktop environment (that is also cross-platform).

Of course, this post is about libghostty, the underlying term emulator library. And that is an amazing contribution to the ecosystem! Zmx, herdr, soon neovim, now emacs, hopefully someday Zed – so many things can now embed an amazingly performant terminal