3 ms·
This doesn’t sound like a “you might not need tmux” argument. It more just argues than tmux is a pita on the terminal ecosystem which I’m sure is true. But the
by pure-orange 1y ago
This doesn’t sound like a “you might not need tmux” argument. It more just argues than tmux is a pita on the terminal ecosystem which I’m sure is true. But the workarounds described are just reimplementing tmux features by taping together a bunch of tools. A better argument I think is - a lot of people do need tmux, so perhaps we should rethink protocols etc to make many of these features more native
- deleted 1y ago[deleted]
- charcircuit 1y agoIt's more like you don't need to use a webpage that offers tabs using iframes because the browser natively has tabs that you could be using instead.
- pastage 1y agoHaving native scroll back should be possible if you hack tmux and a terminal emulator.
- dizhn 1y agoweztern has a really strong solution in this space when you use it with its multiplexing server on the remote end.
- mananaysiempre 1y agoAt one point I was wondering if there was a preexisting protocol for a character-based framebuffer of some sort, that we could then use to slice the problem in a different way: a framebuffer multipliexer running terminal emulators inside it instead of a terminal multiplexer emulating multiple terminals into a framebuffer and then translating it back into terminal controls for the parent. Unfortunately, my conclusion was that the only independent character-based terminal tradition is IBM’s 3270 stuff, but even setting aside IBM weirdness it’s simply not that. (Yes, there’s also such a protocol within tmux but it’s not really compatible with anything else.)
- rollcat 1y ago> It more just argues than tmux is a pita on the terminal ecosystem which I’m sure is true. Start thinking of tmux, screen, ssh, etc as terminal emulators, and everything will suddenly make sense. > perhaps we should rethink protocols etc to make many of these features more native I've been opposing terminal emulators (NOTE: emulators, not REPLs) for a long while. I also do believe we can collectively do better than emulating 1970s hardware. I do believe we can build applications where "ctrl-c" means copy, and selecting more than one screen's worth of text is possible. It's not hard, we're just stubborn.
- em-bee 1y agonitpick: ctrl-c never meant copy until windows started to dominate. it didn't even mean that in DOS. selecting more than one screens worth of text is possible in gui terminals and also in tmux. but i agree with your general point: we can collectively do better than emulating 1970s hardware absolutely!
- rollcat 1y ago> nitpick: ctrl-c never meant copy until windows started to dominate. it didn't even mean that in DOS. VT102 wasn't designed with multiplexing in mind. The device was meant as a primary way to interact with a computer, not to perform the tasks of one - your physical keyboard also doesn't understand "copy". > selecting more than one screens worth of text is possible in gui terminals and also in tmux. It is but it isn't. You want to copy a multiline snippet of code you just wrote, you will have to manually strip away $PS1 & $PS2. You want to copy from vi into another window, you can't use the mouse - and you have to use a side channel. I have 20+ unfixable issues outlined, and I'm in the process of writing a blog post... But at my current rate, it could become a book.
- em-bee 1y agoIt is but it isn't. ok, yes, i was just talking about the simple case. you are right that the issue is more complicated, so i actually agree with you. i am talking about similar problems here: https://news.ycombinator.com/item?id=44757142 https://news.ycombinator.com/item?id=44757142 i am looking forward to your post. i added your blog to my rss reader