baokaola

Have you tried Ghostel for this? I'm one of the Ghostel maintainers so if you have any particular harness that behaves poorly in Ghostel we'd like to know about it so we can fix it.

There's only one language that's more dangerous than C and that is unsafe Rust. I say that only half-jokingly.

Maybe he's talking about claude-code-ide.el which piggybacks on Claude Code's IDE integration. It recently added support for Ghostel too.

Are you thinking about using the scroll wheel of the mouse to scroll within the program? If the appropriate terminal modes are enabled by the application running in the terminal, we capture the scroll events in Emacs and forward them to the terminal instead of letting Emacs handle them.

I'm not entirely sure what you're asking. But I'll answer to the best of my abilities:

For Ghostel, libghostty-vt is the source of truth and the architecture is essentially that we serve input to the PTY and the PTY serves output to libghostty-vt which builds out the state in the form of a terminal screen structure. The goal is then to keep the contents of an Emacs buffer up to date to this terminal screen without replace the entire thing every time we redraw. We make use of mainly two things in order to do as little work as possible: - Scrollback is immutable and thus never has to be modified unless it's evicted, alt screen is activated, dimensions change etc. - libghostty-vt maintains row level dirty flags that we scan to make sure we're only replacing lines that have actually changed.

So for the rendering part, we're only diffing the grid state against the buffer, not doing anything based on terminal semantics per se, parser events that draw to the screen are passed straight to the terminal handler. But of course, certain things we need to hook into such as directory and title changes, of clipboard events etc.

Might also add that we're using the direct Zig API, not the C API, which means we have access to things that aren't exposed in the C API.

This is a known issue that I've been chasing myself. It most likely has to do with the fact that we cannot render hidden buffers (for reasons) so when the buffer reappears again, we have hooks to refresh it. But sometimes it fails to refresh fully.

When are you mostly seeing this? With agent TUIs?

Hehe, the feature that enables that (feeding reading the PTY and feeding the VT parser off the main Emacs thread) only got merged today. But the rendering even before this was a lot faster than Vterm.

Otherwise, I think the main advantage over Vterm and other Emacs terminal emulators is that it handles modern fancy TUIs a lot better than Vterm. It's backed by libghostty-vt so supports all the new fangled escape codes. It has a bunch of tricks to force fallback glyphs to the terminal monospace grid to remove the flickering effect when the glyph cells change size during TUI animations, most notably in Claude Code. Btop and Yazi runs great too, if you're into that sort of thing.

Plus a bunch of other things!

Can you elaborate a bit on what you are asking about?

For real, ask your agent to do anything in Emacs and it simply knows how to do it.

I find Emacs better than ever in the age of AI. Install agent-shell to run Claude Code inside Emacs and give it a skill to run Emacs Lisp using emacsclient. Voila - now you have all the integration you could ever need if you are a little resourceful.

Claude Code can now introspect the entire editor and it can manipulate everything. You can have it build whatever features are missing - it will even debug those features for you, live in the editor.

I recently came back to Emacs from VSCode and ended up just letting Claude build me the features I was missing, mainly related to tabs and project management.

I think Emacs has unique advantages in the age of LLMs, you can just mold it like clay.