I can't help but feel this constant churn of "terminal emulator but with tmux built in" are wildly missing the point.
Terminal + Tmux is great and cool but for very specific reasons. Most of those reasons involve backwards compatibility. You can view "Terminal based UIs" on basically anything that can, you know, emulate a terminal and that's a pretty powerful feature.
Things that consume and output text, even weird marked up terminal text, are very composable with other things that consume and output text.
OmniPTY doesn't seem to have any of these advantages.
Like, I use tmux every day, vim and bash and stuff, all great, genuinely like them, but if we're going to be building new things at the terminal emulator layer, do something new. Give me some meaningfully great new features that are worth changing for.
I've said this before, but web browsers are remarkably similar to terminal emulators. They exist to render content sent to them via remote network servers and such. Terminals use text + a truly horrifying set of embedded escape sequences, web browsers use html.
html is probably 1000 times slower to parse than terminal escape codes (I'm not sure it's actually any harder) but who cares.
The terminal emulator ecosystem is a complicated set of parts, not a single entity. Just at a very high level you have the emulator itself, rendering text/"graphics", you have ssh streaming the text between systems, you have tmux/whatever doing "window management" and then you have bash/whatever acting as the actual user interface to the entire rest of the "linux" system, all the compilers and parsers and file searchers and so on are all invoked via bash.
This is an awful lot of work over the years to iron out the bugs and more or less modify things to work the way people want them to, based on, you know, years of people actually using them. We can't just throw that way, because that way leads to "rewriting successful systems" and that rarely works out well.
But I want to keep all the great stuff about terminal/bash interfaces and get rid of all the bad stuff. I touched on browsers earlier because they're the most obvious upgrade path. They already provide multiplatform network based renderer that runs everywhere and implements standards.
They're actually, perhaps, too powerful, part of the appeal of bash and friends is that the limitations imposed by the terminal emulator framework means that you can't get too stupid with your user interfaces, after all, you are basically limited to outputting a grid of text at most, but surely there's some way to get the best of both worlds.
Let me pitch you an idea: an `ls` that outputs html and is rendered by a browser.
I know, boo hiss, it takes more cpu to render the output and what about my amiga and web browsers are tools of the evil overlords and whatever.
But hear me out. Once `ls` outputs html, you get two cool features right off the bat. First, and more minorly, you get styling "for free" in a standard, cross program way. Because css exists. You get to say stuff like: `ls-output.file { color: green }; ls-output.directory { blue }` or whatever without having to learn whatever bizarre syntax the LSCOLORS feature actually uses.
But that's a minor feature. The way more interesting thing is that you now have structured output. The thing everyone interested in improving bash claims to want. Wrapping the output in html tags might not be the best structure in the entire world, but at least it exists and is usable.
Now you get to write bash command lines like `ls | .file-size | sum` without having to write a custom parser for the ls output (which doesn't even work because ls relies on whitespace to delimit columns and those characters can also exist in filenames so this is a bad idea).
The key to making structured output for bash work is to not make it an alternative. It has to be the required, default, only way of doing output. If you rely on people adding a --json flag to their tool, guess what, they won't do it.
Anyways, I'd like to order two Baconators and a coke, thanks.
I've said this a few times, the terminal+shell is a more than half-century old relic that's 10 years past its expiration date. We need better stabs at innovating power-user workspace management than a new coat of paint on old software.
For what it's worth, it does look rather nice, and it looks as though care has been taken to construct it. Though next to existing solutions with more pedigree, it's hard to argue in its favour.
all software is a reflection of its maker's opinions. README seems AI-generated. not clear what unsolved problem this solves.
I can't help but feel this constant churn of "terminal emulator but with tmux built in" are wildly missing the point.
Terminal + Tmux is great and cool but for very specific reasons. Most of those reasons involve backwards compatibility. You can view "Terminal based UIs" on basically anything that can, you know, emulate a terminal and that's a pretty powerful feature.
Things that consume and output text, even weird marked up terminal text, are very composable with other things that consume and output text.
OmniPTY doesn't seem to have any of these advantages.
Like, I use tmux every day, vim and bash and stuff, all great, genuinely like them, but if we're going to be building new things at the terminal emulator layer, do something new. Give me some meaningfully great new features that are worth changing for.
I've said this before, but web browsers are remarkably similar to terminal emulators. They exist to render content sent to them via remote network servers and such. Terminals use text + a truly horrifying set of embedded escape sequences, web browsers use html.
html is probably 1000 times slower to parse than terminal escape codes (I'm not sure it's actually any harder) but who cares.
The terminal emulator ecosystem is a complicated set of parts, not a single entity. Just at a very high level you have the emulator itself, rendering text/"graphics", you have ssh streaming the text between systems, you have tmux/whatever doing "window management" and then you have bash/whatever acting as the actual user interface to the entire rest of the "linux" system, all the compilers and parsers and file searchers and so on are all invoked via bash.
This is an awful lot of work over the years to iron out the bugs and more or less modify things to work the way people want them to, based on, you know, years of people actually using them. We can't just throw that way, because that way leads to "rewriting successful systems" and that rarely works out well.
But I want to keep all the great stuff about terminal/bash interfaces and get rid of all the bad stuff. I touched on browsers earlier because they're the most obvious upgrade path. They already provide multiplatform network based renderer that runs everywhere and implements standards.
They're actually, perhaps, too powerful, part of the appeal of bash and friends is that the limitations imposed by the terminal emulator framework means that you can't get too stupid with your user interfaces, after all, you are basically limited to outputting a grid of text at most, but surely there's some way to get the best of both worlds.
Let me pitch you an idea: an `ls` that outputs html and is rendered by a browser.
I know, boo hiss, it takes more cpu to render the output and what about my amiga and web browsers are tools of the evil overlords and whatever.
But hear me out. Once `ls` outputs html, you get two cool features right off the bat. First, and more minorly, you get styling "for free" in a standard, cross program way. Because css exists. You get to say stuff like: `ls-output.file { color: green }; ls-output.directory { blue }` or whatever without having to learn whatever bizarre syntax the LSCOLORS feature actually uses.
But that's a minor feature. The way more interesting thing is that you now have structured output. The thing everyone interested in improving bash claims to want. Wrapping the output in html tags might not be the best structure in the entire world, but at least it exists and is usable.
Now you get to write bash command lines like `ls | .file-size | sum` without having to write a custom parser for the ls output (which doesn't even work because ls relies on whitespace to delimit columns and those characters can also exist in filenames so this is a bad idea).
The key to making structured output for bash work is to not make it an alternative. It has to be the required, default, only way of doing output. If you rely on people adding a --json flag to their tool, guess what, they won't do it.
Anyways, I'd like to order two Baconators and a coke, thanks.
I've said this a few times, the terminal+shell is a more than half-century old relic that's 10 years past its expiration date. We need better stabs at innovating power-user workspace management than a new coat of paint on old software.
For what it's worth, it does look rather nice, and it looks as though care has been taken to construct it. Though next to existing solutions with more pedigree, it's hard to argue in its favour.