core: support "overlay" surfaces

[mitchellh]

This is a deep core detail, but I've been thinking about it and want to keep track of my thoughts here.

Background: A "surface" in the core is anything that renders a terminal. For the end user, this may be a window, a tab, a split, whatever. To Ghostty core, its just a surface and it doesn't give two 💩 💩 how its shown to the user or interacted with.

In thinking about #189, one way we can do this is to actually pipe the entire scrollback into a custom program like vim or less and let the user search with a program they're familiar with. This is also quite powerful because they could do other tasks like edit the scrollback (temporarily, not actually in the terminal). Getting the scrollback into a temporary file or pipe isn't difficult at all, but we currently have no way to really execute additional programs on top of the shell.

An approach I think would be powerful for this and other features is to support something I'm calling an "overlay" surface. This is a surface that has its own termio instance, but it shares a renderer with some parent surface, and it can visually overlay on top of the parent either completely or partially.

Another way to consider this proposal is to separate the Surface from a Renderer completely. Another way to perhaps consider this is that a Renderer belongs to a Surface "Group" instead of a single surface. I don't know 100% conceptually what approach is best here.

With this in mind, the suggestion above re: search would capture the scrollback into a temporary file or pipe, then launch say nvim as a new termio instance with its own renderer state, and then overlay this on top of the existing surface.

This can be further used for other features: log messages, a search UI that isn't rich, open some specific command output in a pager, etc. This can also be a good way up front to show errors to the user for example when validating their configuration.

[mitchellh]

Going to close this because I think its completely unnecessary. We're getting comfortable enough with our native UIs that we can just do this natively without any GPU tricks or reusing surfaces.