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.
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.
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.
> Now I am more excited about the major releases; for instance term issues are an issue for me with the aforementioned Claude integration. Not enough to stop me, but annoying.
Being a co-maintainer, I'm a bit biased, but I think you should try Ghostel (https://github.com/dakra/ghostel) if you aren't already. And if you are, you should report bugs so we can fix them :)
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.