High Hopes

[samholmes]

I just discovered this project form https://github.com/Uzaaft/awesome-libghostty and I have high-hopes!

I've been looking specifically the Lua-based, code-over-config, experience for a multiplexer that is also a terminal app.

So far all the ingredients are here:

1. libghostty – solid framework to ensure the terminal experience is fast and robust
2. lua – familiar Neovim experience for plugins and configurability
3. plugins – extend and make the terminal your own just like nvim
4. minimalism – no features to start, add the plugins to configure your environment
5. multiplexing – move multiplexing up the stack and let the terminal app be the programmable control plane to integrate all CLIs into a cohesive experience
6. custom ui – program a sidebar the way you want it. Heck have multiple sidebars! This is a canvas that can adapt to your workspace

Why am I excited? Because CLI apps/programs are great, but there is not a good way to bring them together and have them integrate with each other. There are attempts at this with tmux and even nvim, but we need to combine the good ideas into one app, and it needs to be the terminal app. Why?

1. The terminal is the highest level thing apart from the OS in the stack.
2. The terminal can render more than just text! Cmux renders markdown for example. And I could imagine rendering plugins to render HTML, etc.

Being able to integrate CLIs together such that it feels like vscode or cursor (but for any application/domain) where you can extend it and shape all the pieces together to make what you want.

Is this the roadmap? Am I reading this right? Are my expectations too high?

[sudo-tee]

Thanks for sharing your excitement.

To put it simply, the roadmap is not fully set in stone in my head yet. I really need to put it on paper to help me focus on the bigger picture.

The first part of the roadmap is to have a great multiplexer as powerful as WezTerm and a scriptable UI as flexible as Neovim.

Both of these are already present to some extent in the project, but there are still some rough edges that I am trying to improve. I can already daily-drive the terminal for 90% of my tasks, and I am adding the missing pieces one by one.

I try to keep the core minimal, with a sensible default UX that can be completely customized by the user.

The scope of the project is fairly large, and I will certainly need help to achieve it, especially for the multiplatform aspects. Linux and macOS support, in particular.

As I am currently forced to work on a Windows machine for work, I can only really test it on Windows. This is why my main target is Windows/WSL, as most Windows terminals tend to neglect this use case.

This is a side project that I work on in my spare time, so I want to temper expectations. My time is limited having kids and a fulltime job.

As a full-stack web developer, Zig is not my most proficient language, so I rely quite a bit on AI to help me while steering everything toward the UX I want.

Help and contributions are certainly welcome.

[samholmes]

I'd be down to help and contribute, though the road map needs to be defined and clear so that way I know my contributions are aligned with the vision.

Did anything I mentioned in my initial post misalign with your vision of what you want this project to be?

[samholmes]

There's one idea I had for some time that I never got around to doing, but I think it's worthwhile to do. It's this idea of creating a multiplexer that allows each CLI to implement support for some protocol with a multiplexer, so it becomes sort of a standard.

Here's the idea in a high-level explanation: each program in a shell knows it's in a shell and knows about its environment through environment variables and some other shell-specific things that have been standardized for a while. One new thing that can be standardized by the shell is that, when a program is running, the signals that the program can use to communicate with a shell allow for a handoff of control back to the shell without exiting the program. This is important if the program exists in a multiplexer because now it can know when it's given control over key bindings or the keyboard input. It can signal to the shell when it wants to exit its control. I believe there are already foreground and background standards for this in Unix using commands like fg and bg for process management, so this would be a surface area to explore to implement the protocol. The important part is that a program needs to signal that it's opting into this protocol so it manages the escape sequence. Otherwise, the shell will assume certain escape sequences from key bindings that it manages.

What this allows for is the shell or multiplexer to be able to focus into the app or program that is running within a particular pane. That program could then blur itself or de-focus and bring the key binding mode back to the multiplexer. This creates sort of a NORMAL mode for the multiplexer versus an INSERT mode for when the program is focused. Given a really flexible modal key binding programming interface in Lua, this could be very powerful to manage integrations between programs. All of that could be developed within the control plane layer, which is the multiplexer.

Why do this, though? What is the end goal? The end goal is that you can use the escape key to exit out of a program and go back to this normal mode to navigate around the panes, tabs, etc. Other key bindings could be configured to issue commands and integrations between panes and programs within those panes, much like NeoVim would do this with programs running in different buffers. There would be a key bound to focus into a pane that's currently selected, to then let the keys that are pressed be sent to that program. But the problem is, since the program is now the controller of the keys, the escape key would not work to exit the "INSERT" mode. There would be a default key bind to exit the insert mode that's not Escape and won't collide with any of the programs' key binds. But it would also be nice if the Escape key could work if the program manages the signal to escape the insert mode.

That's the whole reaason for introducing this protocol, but it requires a program to opt into it, which isn't ideal. Maybe an alternative to this could be to always let the multiplexer control the input keys and know when to send the escape key to the program versus when not to send the escape key to the program. This would require some sort of way for the multiplexer to know of the program state, which I'm not sure we could do. But if we could, that would be even more ideal, because then you can just shim in support for any app that uses the escape key.

I wanted to design something like this for some time, and I was thinking of designing maybe an opentui program like tmux. It makes more sense to design it at the application layer with libghostty and some other tools such that you can really start to build out this system beyond just terminal apps. Terminal becomes an application that adheres to this design.

Anyway, I'm curious to hear your thoughts if this is something that could be spec'd out and you're interested in doing.

[sudo-tee]

This is an interesting idea. And could really improve things. However creating such a protocol is a masive undertaking. Especially having major multiplexers support.

I'm not against the idea, but at the moment I lack time to add such a protocol.

For the moment there is the hollow.htp implementation which let's you talk to the multiplexer and query status. It works with escape sequences. And any app can control the multiplexer. It's not a fully battletested prtocol, but it works for my daily usage.

[sebastianstudniczek]

Regarding multiplexers, do you plan to improve integration with tmux (synchronized rendering as an example) or currently your focus is mainly on built it multiplexing functionalities?

Asking cause cause I noticed some issues when using with tmux but if that's not in scope currently then I will not raise related issues

[sudo-tee]

My current focus is mainly the built-in multiplexer, but if there are issues with tmux, I can have a look at them.

By synchronized output do you mean tmux control mode (tmux -CC) ? or something else ?

[sebastianstudniczek]

By synchronized output do you mean tmux control mode (tmux -CC) ? or something else ?

Here is description of this feature https://github.com/contour-terminal/vt-extensions/blob/master/synchronized-output.md
and related issue in wezterm wezterm/wezterm#7629

I actually stumbled across this feature when I was searching fix for cursor flickering when using something like fidget.nvim in neovim

[sudo-tee]

Thanks for the links, I will have a look at this

[sudo-tee]

@sebastianstudniczek

I created a PR to support synchronized rendering.

In the PR there is a build you can download and try. Let me know if this helps with your tmux issues you described.

#16

Thanks

[sebastianstudniczek]

That was fast, thanks :) I will check it and let you know next week since currently I am off and don't have access to my computer.

[sudo-tee]

That was fast, thanks :) I will check it and let you know next week since currently I am off and don't have access to my computer.

I decided to merge it as it is, but feel free to let me know if it works properly for you.

[sebastianstudniczek]

I recently found out about Mitchel building new terminal multiplexer. Looks this might be great addition for libghostty based terminal emulators (multiplexing with raw bytes streaming to client)
https://m.youtube.com/watch?v=Y6nFMmUPzXM

[sudo-tee]

@sebastianstudniczek

Yes I also saw this, if this works well it might changes the scope of this project. But I will surely keep an eye on it