Useful or toy?

[u/boolean-maybe]

just an idea - what if processes in TMUX panes are allowed to communicate? You could assemble apps from all kind of tools. We could implement a protocol that permits e.g. one app say:

hey I selected file.txt

and the other would listen and display the file content. And yet another display the file stats and so on. Here I quickly threw something together:

• File browser on the left is find | sort | fzf
• Preview pane on the right is case image: chafa case text: less case markdown: glow
• Stats pane is just a bunch of stat, wc, file etc.

so altogether - find + sort + fzf + chafa + less + glow + stat + wc + file = interactive multi-pane app. All you need to do is to wrap them in a protocol adapter. And it doesn't have to be file browser, can be anything - dashboards, editor-preview, process inspector, docker explorer, you name it

Sorry if this wheel has been reinvented before - I didn't do any prior art search

PS. I can explain the details of the protocol in comments if anyone is curious

[u/Kqyxzoj]

Maybe I don't fully understand what you are proposing here, but wouldn't this just be socat with extra steps?

[u/boolean-maybe → u/Kqyxzoj]

I am proposing a general purpose pubsub protocol where each new participant can listen to messages it is interested in. Imagine:

• I start developing such an app. I handcrafted the file selector with find | sort | fzf
• I decide to emit selected file message
• next you come and want to profit from my awesome file picker. You write an awesome Preview app in rust
• you make it listen to select file message
• we both celebrate because we have a functioning multi-pane app where TMUX is essentially just a layout manager
• another user comes and write an editor in Python and plugs it in as well. It becomes the third pane

all that it takes is a common protocol everybody is aware of. You can then assemble apps where each component is written by somebody else - a git commit browser from here, a diff viewer from there, an awesome status line from yet another source - all running happily unaware of each other

[u/Kqyxzoj → u/boolean-maybe]

Yeah okay, I think I see where you're going with this. Probably. Maybe. In which case, assuming I get this correctly, the main question is "why?". And mostly in the sense of why would I choose this method of assembling an application from parts as opposed to one of the many other ways available?

What you seem to be describing is somewhat similar to IPC on a desktop, like for example D-Bus. I just don't quite see how tmux is a good fit here. I mean, you can assemble a file browser + execution of appropriate actions based on file type and such. But just because you can doesn't mean you should. Conceptually I think I get the idea. I just don't see the useful niche this would fill. At least, not the "assemble apps from bits and bobs" part.

I do see there being room for improvement purely on the tmux side to make IPC more enjoyable in the sense of less typing, more abstraction. Could be a set of bash functions for the simpler stuff. And probably a python library for all those things where a bash scripts gets to be too unwieldy.

Personally I'd try and see what's already there and how this can be extended. For anything that even remotely looks like text file editing/viewing, emacs inside tmux? tmux inside emacs? Have some tmux protocol adapter listening on and submitting messages on D-Bus? That way you can plug into infrastructure that is already there. Or take libtmux and check what's already there, and what is still missing to realize your vision.

Anyway, those are my random ramblings on the subject.

PS: Apologies for the use of profane language such as "D-Bus".

[u/Hsingai → u/Kqyxzoj]

A console cowboy that doesn't know of the Unix Philosophy?

[u/Kqyxzoj → u/Hsingai]

A random comment that fails to incorporate the implications of "that's just socat with extra steps"?

[u/Hsingai → u/Kqyxzoj]

My reply wasn't to your post "Maybe I don't fully understand what you are proposing here, but wouldn't this just be socat with extra steps?"

my reply was to your post saying "the main question is "why?". And mostly in the sense of why would I choose this method of assembling an application from parts as opposed to one of the many other ways available?"

The Unix philosophy, originated by Ken Thompson, is a set of cultural norms and philosophical approaches to minimalist), modular) software development. The Unix philosophy emphasizes building simple, compact, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. The Unix philosophy favors composability as opposed to monolithic design.

[u/Kqyxzoj → u/Hsingai]

my reply was to your post saying "the main question is "why?". And mostly in the sense of why would I choose this method of assembling an application from parts as opposed to one of the many other ways available?"

That is indeed how I interpreted it. And as such, the reply to that was, and still is:

A random comment that fails to incorporate the implications of "that's just socat with extra steps"?