In-buffer Eshell support

[MagielBruntink]

Eat has this wonderful feature that runs visual programs inside the Eshell buffer (eat-eshell-mode). Unfortunately, it seams eat is not getting much maintenance anymore and is lagging behind in terms of other features that e.g. ghostel offers. Are you considering Eshell support like eat as well?

[dakra]

Since you wrote 'visual programs', we have an eshell extension,
that automatically runs programs that are in eshell-visual-commands in a Ghostel buffer. And you can ad-hoc run them in Ghostel by prefixing any command with ghostel (can be aliased to a shorter name of course).

Is that enough for your needs?
I know eat has "full" eshell support in that eshell is using eat as a renderer.
I personally haven't used that feature of eat. That integration would obviously be a lot more work than
simply patching the eshell-visual-commands like we do now.
If that's what you meant, I would first want to learn a bit more about your usage of that feature and why
it's useful.

[MagielBruntink]

With the extension, visual programs run in a separate ghostel buffer. The usefulness of the eat feature is that it runs visual program in the same buffer as eshell, with output interleaved by "normal" eshell prompts and interaction. It's useful for inspecting workflow, copying text, etc.

[dakra]

I already had a look at this a while ago when researching the comint integration and before creating the visual commands eshell extension.

I just had another look, and it would not be easy to implement.
In Ghostel the terminal owns the entire buffer while in eat it is by design "region-relative".
And we would need to change ghostel to also support that.

I even have a PoC here that does that (for comint specifically) but that adds (a lot) of complexity for a very niche use-case.

So unfortunately I'm tempted to close this as won't fix :(
@emil-e do you have an opinion?

[emil-e]

@dakra I'm not familiar with how this would work. Would it just drop the output of a command into the Eshell buffer? Or would it run continuosly?

[dakra]

Would it just drop the output of a command into the Eshell buffer?

No, as the main reason to have Ghostel (or eat) as a backend is to run proper tui apps.
(or just spinner/animation stuff)

Or would it run continuosly?

Also not. If I understood it correctly eat (and ghostel would need to do that then as well) creates a new terminal (on a region) for each command. Once the command is finished it's frozen and just a normal part of the Emacs buffer.
That would make better comint integration also possible as comint also relies on those fixed/frozen prompts/markers.

It's not that we couldn't do it, but imho comint is really not worth it and even this eshell use-case while I see the appeal is quite a hack and more complexity in our code.

[emil-e]

I mean... it's certainly possible to implement... maybe if you render from a marker instead of point-min. However, it would add quite some complexity... like how do you handle alt screen? How do you handle terminal sizing? It's not impossible and we could probably abstract the drawing target some, or break out some rendering utilities out of Renderer.zig, but the complexity has to be worth it. I can't really tell since I wouldn't use it myself and I also have other things that I want to tackle before, such as Windows support and revamping the Kitty graphics support.