Guys, did you know about tmux control mode? It tells the host terminal to treat tmux tabs as actual tabs in the terminal. That means that things like scrollback, tab navigation, copy paste, keyboard shortcuts, etc are all handled natively, and you can visually see all your tmux tabs! It doesn't have great support across all terminals, but it does work great in iTerm 2.

Try `tmux -CC` in iTerm.

For a tmux novice like me, this was a total game changer :)

▲ 2oMg3YWV26eKIs a day ago | parent | next [-]

Very cool. Opening the tmux session in a new tab rather than a new window was an improvement that I wanted when I tried this. Here's how to do it: https://stackoverflow.com/a/54756013/22828008

▲ kelsey98765431 2 days ago | parent | prev | next [-]

this is the only reason i use a mac and in a decade no open source linux terminal has ever implemented this to my knowledge

▲ hnlmorg 2 days ago | parent | next [-]

I have in https://github.com/lmorg/ttyphoon

I actually don’t like control mode much though. It’s a terrible protocol. Absolutely abysmal design which leads to a plethora of edge case bugs.

At some point I’ll replace tmux control mode entirely but for the moment it solves the immediate problem.

▲ em-bee 2 days ago | parent [-]

interesting, i am trying to install it to give it a try. the features in ttyphoon look very promising.

unfortunately the build now fails with "frontend.go:39:12: pattern all:frontend/dist: no matching files found"

i am also a bit taken aback by the many dependencies. with heightened risk of supplychain attacks and dependency failures that feels a bit scary.

▲ hnlmorg a day ago | parent [-]

> unfortunately the build now fails with "frontend.go:39:12: pattern all:frontend/dist: no matching files found"

How are you trying to build it? Are you calling make? Also what OS are you on?

    make build

> i am also a bit taken aback by the many dependencies. with heightened risk of supplychain attacks and dependency failures that feels a bit scary.

Yeah, I agree with you there. Most of my projects are very conservative with their dependencies; as was this one too, originally. But this project was just too large for one person to realistically manage on their own and without reusing the hard work of other libraries.

Unfortunately, the two libraries I need to lean on the most are exactly the kind of libraries that will have big dependency trees:

- GUI (Wails): just because there is a huge amount of code required to draw anything to screen

- AI (langchaingo/mcp-go): though mostly for tool use here but they’re optional

Both of these libraries were chosen because they are well maintained and have a high number of contributors/eyeballs On the code. But, as you said, the risk is still there.

▲

em-bee a day ago | parent [-]

i have fedora. and yes, i am running make build.

why did you choose wails btw? did you look at fyne? it's go-native and it seems to have a lot less dependencies.

can the AI integration be turned off? i am not going to use it myself.

is there a chatroom where we can talk through debugging my build problem? github issues? you didn't turn in the discussion forum for ttyphoon like you did for murex. or is there another place where you hang out? hn is not exactly the ideal place to talk through dev issues.

▲

hnlmorg a day ago | parent [-]

An earlier build used SDL directly. There were reasons I didn’t choose Fyne and that was basically that the effort wasn’t much less than working directly with SDL due to various (potentially self imposed) constraints.

I then switched to Wails because I wanted to add Markdown, Jupyter support. And other things too. Quickly I realised it was too much for me to attempt SDL (even just the markdown parser proved an annoying time sink) on my own. I think the terminal itself is worse for change so there might be a point when I revisit this switch and change my mind again.

There was a brief period when both Wails and SDL were supported front ends. The idea being you could chose one based on a Go compiler tag. But that proved hard to maintain.

There was also a time when the terminal was SDL and Wails just did the markdown stuff. They were different applications that passed messages via a rudimentary IPC. But that resulted in a multi-window hacky mess.

So the current design is the compromise I’ve settled on but will likely change my mind at some point again.

As for the AI, there isn’t any compiler flags to disable it. But it doesn’t work without you supplying an API key anyway. And the integration is just a few menu items so, hopefully, not intrusive. Which would also make it pretty easy to hide those options behind a compiler flag.

I’m happy to chat as a GitHub issue if you’d prefer. I don’t hang out in may other places these days (time constraints)

	▲	em-bee a day ago \| parent [-]
		thanks for those details. your approach is very pragmatic and i appreciate that. on AI, i am not concerned about a few menu items, but if we want to consider supply chain attacks as a risk, the less that gets downloaded and built, the better. i'll open an issue then, i figure this is more for the benefit of other users of ttyphoon, and since this post is originally about tmux we are already off topic anyways.

▲ MisterTea 2 days ago | parent | prev | next [-]

The control mode feature was implemented by the developer of iTerm2 for iTerm2: https://github.com/tmux/tmux/wiki/Control-Mode

▲ nateglims 2 days ago | parent | prev [-]

Wezterm has some support for it on nightly.

▲ tanvach 2 days ago | parent | prev | next [-]

Was about the mention this, -CC has been working perfectly for me

▲ pmarreck 2 days ago | parent | prev | next [-]

work in ghostty yet?

	▲	saagarjha a day ago \| parent [-]
		Not yet

▲ mwpmaybe 2 days ago | parent | prev | next [-]

Holy carp.

▲ chromejs10 2 days ago | parent | prev [-]

so THAT's what -CC does...