[HN Gopher] Replacing tmux in my dev workflow
___________________________________________________________________
Replacing tmux in my dev workflow
Author : elashri
Score : 214 points
Date : 2025-08-01 09:04 UTC (13 hours ago)
(HTM) web link (bower.sh)
(TXT) w3m dump (bower.sh)
| znpy wrote:
| Sounds like work-arounds and duck-tape-tier re-implementation of
| tmux features, to be honest.
|
| I'm still a gnu screen guy, but for me the trade-off is still in
| favour of screen/tmux.
| pure-orange wrote:
| 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
| charcircuit wrote:
| It'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 wrote:
| Having native scroll back should be possible if you hack tmux
| and a terminal emulator.
| dizhn wrote:
| weztern has a really strong solution in this space when you use
| it with its multiplexing server on the remote end.
| mananaysiempre wrote:
| At 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 wrote:
| > 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 wrote:
| nitpick: 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 wrote:
| > 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 wrote:
| _It 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
|
| i am looking forward to your post. i added your blog to
| my rss reader
| mananaysiempre wrote:
| Nit: didn't Ctrl-X/C/V come from the original Macintosh? I
| thought Windows initially followed IBM's CUA, where cut /
| copy / paste are instead Shift-Delete / Ctrl-Insert /
| Shift-Insert (and those still work too).
| layer8 wrote:
| The original Macintosh had Command-X/C/V, and Windows 3.0
| adopted that in addition to the existing CUA shortcuts,
| but changed Command to Control, as Alt was already in use
| for menus and form control shortcuts on Windows. So it's
| true that Ctrl+C for Copy only became a thing with
| Windows.
| em-bee wrote:
| ah, that's a history detail i didn't know about. very
| well, it's apple's fault then :-)
| anthk wrote:
| That's Emacs for you. No, seriously. Have a look to eshell
| and elisp.
| ivanjermakov wrote:
| Most important tmux functionality is substituted with a window
| manager and a terminal emulator with normal mode support:
| https://wiki.archlinux.org/title/Alacritty#Vi_mode_and_copy/...
|
| But I agree that tmux sessions are convenient.
| imcritic wrote:
| Correct statement, but poorly chosen alternatives: zellij is like
| tmux, but with less scrollback issues and supports mouse.
|
| It is also extensible.
| seanhunter wrote:
| Zellij is great. I have been very happy since I switched over.
| belter wrote:
| You did not hit any of these (many) issues?
| https://github.com/zellij-org/zellij/issues?page=1
| seanhunter wrote:
| Nope. I use it with alacritty and I don't do things like
| trying to click on the bar etc that people are reporting as
| bugs. I have no idea why you would even do that. If you
| drive it from the keyboard as a "better screen/tmux" it
| works great. At least it does for me.
| tux3 wrote:
| People here are missing the point of the solution described in
| the blog post.
|
| This isn't about reinventing tmux poorly. They're trying to keep
| their workflow _without_ having a muxer in the middle that needs
| to understand and translate every feature of the protocol, which
| is the core concept and the major problem with tmux.
|
| If you do splits client side, you don't have any software
| middlebox trying to interpret the traffic, so you keep native
| scrollback and all the fancy features of your terminal are still
| here.
|
| That's what the blog post is about. Not reinventing tmux, but
| getting rid of the muxing.
| mongol wrote:
| In the Youtube interview with Goyal linked in the post, he
| explained this well. He said he contemplated developing another
| approach for this if he found time, where the multiplexer
| communicated with the terminal differently. Hope he gets to
| work on it.
| kzrdude wrote:
| I recommend the interview, it's very good. It should be
| available in podcast form as well. The Kitty author comes
| across very well in the interview
| sligor wrote:
| Yes the clean and efficient alternative would be a session
| manager "server" running on the server and communicating with the
| terminal "client" (like kitty) using a more efficient protocol
| for handling panes/windows/drawing etc...
|
| AFAIK this doesn't exist, so I'm using tmux...
| sligor wrote:
| well after a quick search it exists: it's called tmux control-
| mode https://github.com/tmux/tmux/wiki/Control-Mode
|
| So terminal clients just have to implement this protocol...
| it's already implemented in iTerm2
| panki27 wrote:
| Switching to WezTerm has completely eliminated the need for tmux
| for me - except for stuff I want to run server side, disconnect
| and come back to.
| bezmiran wrote:
| `wezterm ssh` can do this if wezterm is installed on the host.
| zeendo wrote:
| Yeah - it seems like this is a pretty undersold feature of
| WezTerm. It has completely eliminated tmux and Zellij for me
| outside of pairing with others.
| barnabee wrote:
| I agree. I've used first Kitty and more recently WezTerm (and
| now occasionally Ghostty, too) for years and every time I've
| tried tmux/zellij I've found nothing (except as you say for
| occasional long running server sessions) in either that
| justifies the noticable latency increase for me.
| strobe wrote:
| same, and those 2 plugins together completely eliminated need
| for tmux/zelij locally
|
| - https://github.com/MLFlexer/smart_workspace_switcher.wezterm
|
| - https://github.com/MLFlexer/resurrect.wezterm
| zeendo wrote:
| These seem nice but honestly feel like overkill for the most
| basic (and probably most typical?) use of tmux and similar.
|
| I generally have a single session I care about per machine
| (rather than per project) and wezterm's built-in multiplexing
| handles this out of the box.
| aragilar wrote:
| Maybe I'm a bit weird, but I don't know why you'd want to run
| tmux locally as an alternative to using tiling wm/tabs/other
| equivalent feature of your terminal emulator? I use tmux in two
| ways: 1. Persistent long-running sessions (which typically
| involve having more than one tty going at once, so something
| like shpool seems like a downgrade). 2. Local named-network-
| namespace sessions where I'm connected to a VPN and so not
| having to reconnect to the same namespace/vpn for every new tty
| is a benefit.
|
| Also, if you do physically connect to a headless machine, it's
| nice to not need to keep having to open a new getty session (or
| be able to log out of a session) ;)
| em-bee wrote:
| i have 5 tmux sessions with a total of 19 windows on my
| laptop, one of which contains a localhost ssh connection to a
| second account where i have another tmux session with half a
| dozen windows. not to mention the tmux sessions i have on my
| servers.
|
| the key benefit is i only need to learn one set of commands
| to switch sessions and windows, and to create new windows.
|
| the sessions all run in a single terminal window, so when i
| have multiple other windows, i don't have to switch between
| them to find the right terminal window. terminals have tabs,
| but they don't group tabs into sessions. a single terminal
| with 19 tabs would not work.
|
| i use the gui to start the terminal. i would have to find out
| how to script starting a terminal with multiple tabs. tmux is
| more easily scriptable, and again, i can't avoid learning
| tmux, since i use it remotely, and so when using it locally
| too, i don't have to learn a different way for my local
| machine.
|
| finally, although rarely needed, i can log out, or my gui can
| crash, but the tmux sessions survive. i can also connect to
| my laptop from a different device and attach to the tmux
| sessions that way.
|
| for a gui terminal to replace tmux the foremost feature i
| need is for it to remember my windows and tabs, just like the
| browser does. i have not come across any terminal that does
| that (but i admit, i haven't done a exhaustive search
| either). gnome (or any WM) can remember which apps i have
| open, but it can't remember the state inside the apps.
|
| being able to reproduce state is really the key. i have a few
| vim sessions for example, easily remembered and recalled from
| my command line history. i could use gvim if i could figure
| out how to connect a gvim window with a terminal such that
| they form one unit, because every vim session is connected a
| number of commandline operations. (i believe BeOS/haiku can
| potentially do that based on the way its window tabs work)
| atq2119 wrote:
| > localhost ssh connection to a second account
|
| Any particular reason why you cannot simply use su or sudo
| for this?
| em-bee wrote:
| it would not make a difference, would it? do you see any
| benefits? ssh -X can forward windows to my gui and it
| just works.
| rkangel wrote:
| Two reasons:
|
| I don't use a tiling WM, and tmux[1] does an excellent job at
| the tiling features.
|
| I do the majority of my work physically at a Linux (Fedora)
| desktop, but I also work from home SSH'd to that desktop.
| Being able to just attach to the same session and pick up
| where I left off, with all the same shell management, is
| great.
|
| [1] I used tmux for years, but have very recently switched to
| Zellij. I find the pane navigation to be much smoother (and
| more discoverable).
| zeendo wrote:
| Run WezTerm on the server, too.
| https://wezterm.org/multiplexing.html
| panki27 wrote:
| Thank you, already knew about it though.
|
| WezTerm is not necessarily something I want to deploy and
| keep up to date on hundreds of machines, screen/tmux are
| still fine for that.
| selectnull wrote:
| I'm the same. And I run tmux on server when needed. Best of
| both worlds.
| mickeyp wrote:
| Better still, use Emacs as your terminal multiplexer:
|
| https://www.masteringemacs.org/article/replacing-tmux-gnu-sc...
| squishington wrote:
| Named buffers combined with helm is so good!
| cluckindan wrote:
| Emacs is such a powerful tool, all it's missing is a workable
| text editor ;-)
| jwrallie wrote:
| It does have evil mode ;)
| linhns wrote:
| Configuring in evil is a nightmare.
| plett wrote:
| I view "you might not need tmux" in the same way as "you might
| not need browser tabs".
|
| Yes, if you only have one or two terminal sessions or open web
| pages then you can probably live without using them, but anything
| beyond that leads you into reimplementing features to cope with
| your desktop's lack of ability to manage dozens of windows.
| 3036e4 wrote:
| That is something I have strived for recently, to use all the
| great window management features of my window manager of choice
| instead of browser tabs or lots of terminal tabs running tmux.
| If that didn't work well I guess it would have been a good sign
| that I need a better window manager. Even went back to use
| bookmarks instead of leaving hundreds of tabs open and having a
| bookmark bar instead of a tab bar is not bad at all.
| tezza wrote:
| MS Windows has excellent multi window management with Alt Tab
| Win Tab etc. Far superior to others.
|
| I have all my terminals with distinct icons and background
| colours to tell them apart. The operating system (Windows) does
| the heavy lifting.
|
| i tried Mac for about five years but missed MS Windows "every
| window can be alt tabbed to". Mac has "every app can be command
| tabbed to and therein each app has its own subwindow
| management"
| joleyj wrote:
| > "every app can be command tabbed to and therein each app
| has its own subwindow management"
|
| This is so, so annoying. Your Mac app's window is minimized?
| No alt-tab for you!
| foldr wrote:
| Just don't minimize the window. Removing a window from the
| alt-Tab list is basically the only reason to minimize it in
| the first place on Mac. (Not reflexively minimizing windows
| does take some time to get used to if you're coming from
| Windows, admittedly.)
| squigz wrote:
| Macs must have some strange workflows that that's the
| only use for minimizing...
|
| I regularly minimize some applications when I want to
| focus on others.
| em-bee wrote:
| you can use workspaces for that. for comparison, gnome on
| linux doesn't even support minimizing windows any more.
| you move windows/apps that you don't want to use right
| now to a different workspace.
| wtallis wrote:
| You can also hide an entire application rather than
| minimizing specific windows. It'll unhide when you switch
| back with cmd-tab.
| foldr wrote:
| Minimization on Mac is essentially a legacy feature.
| There's rarely any reason to use it.
| layer8 wrote:
| On Windows there are applications that minimize to the
| tray instead of remaining on the task bar. That's my most
| common reason to minimize, so that it disappears from the
| task bar when not in use.
| sceptic123 wrote:
| Just CMD+TAB to your required app, then hit | arrow and you
| get access to all your windows. Minimised windows appear at
| the bottom of the screen.
| anthk wrote:
| WindowMaker under GNU/Linux and BSD was like that too...
|
| But, OFC, both WindowMaker and Mac OSX come from the same
| NeXT grandaddy...
| em-bee wrote:
| well, windowmaker only copied the style, so it's more
| like a reverse adoption, not a descendant.
| mkl wrote:
| > MS Windows has excellent multi window management with Alt
| Tab Win Tab etc. Far superior to others.
|
| If by "others" you mean Mac, okay, but KDE and some other
| Linux desktops are at least as good as Windows at this out of
| the box, and much more customisable.
| squigz wrote:
| Windows has _basic_ window and desktop management, but I
| would hardly describe it as excellent. Most tiling window
| managers would provide those features and then more.
| sceptic123 wrote:
| Whatever fits your mental model I suppose, but every window
| is accessible via keyboard shortcuts on the Mac too, it just
| needs a different approach.
| coldpie wrote:
| Do you know if there is a way to quickly switch between
| only two individual windows in different applications? A
| very common paradigm for me is swapping between two
| windows, for example a terminal session for code editing
| and a browser window for reference. On Windows and most
| Linux WMs, this is just a quick alt-tab hit to toggle
| between the two most recently focused windows. As I know
| there is no way to do this on macOS without bringing _all_
| the windows to the foreground, which is not what I want.
| This is my #1 complaint about macos, I'd be so happy if
| there is just some shortcut I'm missing to accomplish this.
| sceptic123 wrote:
| I'm pretty sure that's part of what stage manager is for
| -- you can drag windows in the same stage and they
| operate how you want -- but there's too much manual setup
| required for me to realistically suggest it as an
| alternative.
|
| There are a bunch of third party tools you can use
| though, [AltTab](1) is free and tries to replicate
| windows experience on Mac. [Raycast](2) has a Switch
| Windows command which also allows direct access to any
| window via the keyboard (bind to alt+tab if you like)
| amongst many other features.
|
| [1] https://alt-tab-macos.netlify.app/ [2]
| https://www.raycast.com/
| coldpie wrote:
| Yeah unfortunately my work doesn't allow 3rd party apps
| like that (a reasonable restriction, IMO).
| anthk wrote:
| Alt-tab? You mean pressing win+w under CWM to fuzzy-find
| windows per title name, and then spawn it?
| bravesoul2 wrote:
| But many terminals have tabs so if all you desire is more than
| one terminal open but not multiple ui windows there are other
| options. VSCode for instance!
| jefurii wrote:
| byobu+tmux lets me log into a remote machine _once_ and then
| have multiple named sessions /workspaces each having multiple
| named tabs. The sessions persist when I disconnect and are
| there when I reconnect the next day. Is that possible with
| terminal tabs?
| kccqzy wrote:
| I have come to believe that tab management is really the job of
| the window manager not individual apps. My window manager
| allows me to tile windows, or create tabs out of overlapping
| windows. The tabs can be from the same app or even different
| ones.
| rnhmjoj wrote:
| I stopped using tmux, but not for the reasons mentioned here. I
| think tmux is perfectly fine, I just don't like the default
| keybindings and I could never remember how to copy/paste between
| windows.
|
| I've switched to abduco for persistance and use neovim for window
| management (both vim and neovim have a built in terminal
| emulator). Using vim keybindings for managing windows and tabs is
| more natural, I can copy/paster just normally and you even get
| some perks like `gf` to quickly open a filepath under the cursor.
| em-bee wrote:
| is the vim terminal support that good now? i remember it being
| brittle. some apps, especially apps that use the full terminal
| window didn't run well inside the vim terminal.
| rnhmjoj wrote:
| The neovim terminal is pretty decent, the only feature I miss
| is reflowing the text on resize. I haven't used the vim one
| extensively, but I've heard it may even better than the
| neovim one.
| ramon156 wrote:
| Zellij has started to become messy in my setup (i don't mean to
| blame zellij, i just suck), so I'm looking into tmux now.
|
| I liked the fact I didn't need to set anything up for Zellij and
| could gradually add stuff
| nobleach wrote:
| I gave Zellij a shot a few months ago. It really felt too
| "modal" for me though. I've been a Vim user forever so I'm not
| exactly modal-averse. But TMUX has always felt more like
| Operator Pending mode in Vim. Having Zellij feel like full-on
| Normal mode was frustrating. After I gave up, someone told me
| they had their Zellij configured just like TMUX, and I should
| give it another shot with their config. I still haven't gotten
| around to it.
| em-bee wrote:
| could you share that config please? as a tmux user i feel
| like i might run into the same problems, and so a tmux like
| setup might be a good start.
| metaltyphoon wrote:
| Zellij has added a "locked" mode (defaults to Ctrl + g) where
| it acts just like Vim's normal/insert modes. So when to do
| mux commands you unlock it first.
| wheybags wrote:
| > act as a drag on the ecosystem as a whole, making it very hard
| to get any new features
|
| I dont see this as an issue though. Terminals are pretty much a
| solved problem, they dont need any new features. IMO it makes
| more sense to spend effort on improving tmux<->terminal interop
| rather than adding fancy graphics protocols that we dont actually
| need.
| em-bee wrote:
| it's not fancy graphics that's missing from the terminal. but
| things like selection of text areas. (you can only select
| across the whole screen now, and if you are lucky you can
| select rectangles. but if i display text in multiple columns
| i'd like to be able to select one column at a time for example.
| this bites me every time when i use tmux or vim split windows.
| also filesystem navigation could be improved, multiline
| commandline editing is sorely lacking. fish tried that, but
| failed to make it work. clearly a limitation of the terminal.
|
| so no, terminals are not a solved problem.
| cestith wrote:
| Vim itself can select a column.
| em-bee wrote:
| but it's non-trivial to copy that selection to the outside
| of vim to another app.
|
| i can select a column in tmux too, using tmux commands, and
| then it's the same problem. i can't use that selection
| outside of tmux.
|
| i simply want the GUI to be aware that there are multiple
| columns in the terminal and let me select text within one
| using the mouse and then copy that to a different
| window/app.
| mananaysiempre wrote:
| > it's non-trivial to copy that selection to the outside
| of vim to another app
|
| A correctly compiled Vim will make the two X clipboards
| ("selections") available as registers * ("primary", i.e.
| the current selection, pasteable with the middle mouse
| button) and + ("secondary", accessed with Ctrl-X/C/V) for
| both reading and writing. (I believe these are synonyms
| in graphical environments that don't have two
| clipboards.) You can make one of them the default by
| adding set clipboard=unnamed
|
| resp. set clipboard=unnamedplus
|
| to your Vim configuration.
|
| > i can select a column in tmux too, using tmux commands,
| and [...] i can't use that selection outside of tmux.
|
| If you're using Wayland on Linux, install wl-clipboard
| and put set-option -s copy-command wl-
| copy
|
| in your tmux configuration, and mutatis mutandis for
| other (local) graphical environments. Watch out for cases
| where you've trained yourself to assume that the tmux
| selection and the desktop's clipboard aren't the same
| thing. (I don't know how I'd synchronize things in the
| other direction, that seems non-trivial.)
| em-bee wrote:
| thank you. getting this to work would be awesome.
| mananaysiempre wrote:
| Now that I'm looking at this again, I remember that the
| wl-copy (or xcopy or pbcopy) thing is a workaround for
| GNOME's VTE terminal widget refusing to support the OSC
| 52 escape sequence for setting the clipboard. If your
| terminal emulator does speak that one, then you should be
| able to use the set-clipboard option[1] instead, which
| also has the advantage of working over a remote
| connection (because it's in-band).
|
| [1] https://github.com/tmux/tmux/wiki/Clipboard#the-set-
| clipboar...
| esjeon wrote:
| Interestingly enough, suckless folks took the opposite approach
| with their terminal:
|
| > Goals ... Do not reimplement tmux and his comrades.
|
| ( From https://st.suckless.org/goals/ )
| frantathefranta wrote:
| I'd say suckless and Kitty are pretty much the polar opposites
| of development.
| fandalf wrote:
| i smell copium
| nathan_compton wrote:
| I just use Emacs for this.
| tombert wrote:
| The keystrokes are so ingrained into me that you can take tmux
| from my cold dead hands.
|
| I use it a bit with remote connections, but tmux is basically my
| IDE for development. I have the backtick mapped as my prefix and
| I hope between terminals and Neovim, and I am considerably less
| productive when I don't have this setup.
| sgarland wrote:
| Same. I've also been semi-forced to learn expect due to
| abysmally bad UX for how my company handles security (VERY
| secure, but in the most obtuse way possible), and that's been a
| godsend. Not storing anything locally other than metadata, but
| expect lets me skip the obnoxious manual copy/pasting I would
| otherwise be doing.
|
| Sometimes, the old ways are better. A lot of times, actually.
| dllthomas wrote:
| I use tmux (or screen) as a bag for holding context. I set an
| environment variable before spawning it, and then key a lot of
| things in my .bashrc off that environment variable so I get
| context-specific functions/aliases/vars/etc, and keep them when
| I open a new window in an existing tmux. The single best part
| of this is separate histories for my development vs system
| administration vs whatever, although the rest is still quite
| useful.
| JdeBP wrote:
| > if you do not set TERM with tmux properly, your colors will
| render incorrectly
|
| This is of course true of every other terminal emulator as well,
| and indeed it's not only colours that are incorrect. Function and
| editing keys get recognized incorrectly; REP can get used where
| it does not work; and even simple relative cursor motions can be
| done wrongly.
|
| TERM and the ideas incorporated into terminfo/termcap are
| inherent in the way that terminal devices work on Unices and
| Linux-based operating systems. That there are different terminals
| and terminal emulators not all speaking exactly the same protocol
| is also an unavoidable reality.
|
| Setting TERM properly isn't some tmux-specific problem.
| blueflow wrote:
| Yet the author incorrectly blames it on tmux, which gives the
| article a bad taste.
|
| Also im not sure whether the scolling problem is actually tmux
| fault. Tmux uses the alternate screen buffer, the alternate
| screen buffer is activated using the smcup/rmcup terminfo
| capabilities, whose semantics actually say that it "fixes" the
| window viewport in-place so absolute cursor movement has a
| known zero position. In this state, any native scrolling
| attempt should have no effect, and the keypress/scroll wheel
| events should be forwarded to tmux directly.
|
| For some reason, every other terminal emulator still allows
| local scrolling in the alternate screen, which kinda breaks the
| semantics of smcup/rmcup and easy scrolling in tmux, too.
| aragilar wrote:
| Sadly after experimenting with a bunch of "modern" terminals
| I'm forced to consider that their primary audience is more
| interest in ricing than actually implementing the terminal
| commands (or connecting to anything other than their
| favourite linux box) and so I'm stuck with xterm as the only
| reliable terminal emulator that won't occasionally spew
| unreadable junk.
| sgarland wrote:
| Have you tried Ghostty? Its creator has been pretty serious
| about getting everything right.
| nomad41 wrote:
| I tried it a few months ago and it didn't even have a way
| to search terminal output.
| metaltyphoon wrote:
| That's the most annoying part of ghostty at the moment. I
| have no idea why it isn't a priority :(
| https://github.com/ghostty-org/ghostty/issues/189
| tristan957 wrote:
| Because Mitchell doesn't use terminal search, and neither
| do most of the maintainers.
| metaltyphoon wrote:
| How is this even possible? Just pipe result from a
| command into a file and open in vim and search it that
| way? Perhaps use Neovim's built in terminal where you can
| search at will? I find it hard to believe that "I don't
| ever search" is a thing.
| wredcoll wrote:
| He probably uses tmux which has features for all of those
| things, why should the terminal re-implement them?
| udev4096 wrote:
| Oh yes, using a new terminal emulator instead of one
| which has been around for decades. What could go wrong?
| It's creator has been vocal that it's nothing more than a
| side project
| GuinansEyebrows wrote:
| ironically, the last time i tried it in my normal
| workflow, it refused to interpret certain escape
| sequences... to the terraform cli application. i couldn't
| finish a `terraform apply` - i'd type `y` and hit enter
| but it would just print `^M`.
| t_mahmood wrote:
| And, actually having terminals crush. It is kind of absurd
| to have a terminal crush.
|
| I've tried
|
| Wezterm Ghoatty Ptyxis
|
| First two had some frequent crushes, ptyxis is quiet
| reliable, but I felt it consumes too much memory for a
| terminal. But I feel it's a good terminal.
|
| Though I wish I could get rid of the headerbar
| Modified3019 wrote:
| What is "terminal crush"? I've not heard of this before.
| rstupek wrote:
| I think he's referring to being married to or "crush" on
| the terminal you use
| partdavid wrote:
| I'm assuming "crash"--it's a mild malapropism based on
| some varieties of English phonetics that I've seen
| before.
| t_mahmood wrote:
| Oh, my bad he he, as other corrected
| elzbardico wrote:
| you mean "crash"? But who I am to judge if you have a
| crush on a terminal, some of them are really beautiful in
| their minimalism. :-D
| t_mahmood wrote:
| Ah, terminals ARE really nice, aren't they? Fast and
| efficient. Can't say that for too many apps.
|
| Nevertheless, yeah, I meant crashing, All these years of
| gnome terminal, Tilix I never had them crashing.
| nobleach wrote:
| I agree. It's also true of nearly any program. If you do not
| set its configuration properly, it may not work as expected.
|
| In the case of TMUX, it can be a bit annoying because it's not
| immediately apparent _why_ things look wonky. But I'm not sure
| what the solution is. Default to 256 colors?
| JdeBP wrote:
| Indeed, the TERM environment variable actually _is_ the
| configuration of "nearly any program" (excluding the ones
| that aren't doing explicitly terminal I/O, of course, and the
| bad ones that just ignore TERM and make assumptions). Set
| TERM wrongly, and one has set the configuration incorrectly
| for a whole load of programs, in one fell swoop.
| qudat wrote:
| > Setting TERM properly isn't some tmux-specific problem.
|
| Correct, but it's another layer to deal with. There are `tmux`
| specific TERMs that should be used which sit on top of your
| terminal emulator TERM. This was my point: you have another
| layer that you need to be aware of when using tmux and when
| debugging.
|
| Just look at the top of tmux's FAQ:
|
| https://github.com/tmux/tmux/wiki/FAQ
|
| > PLEASE NOTE: most display problems are due to incorrect TERM!
| Before reporting problems make SURE that TERM settings are
| correct inside and outside tmux.
|
| > Inside tmux TERM must be "screen", "tmux" or similar (such as
| "tmux-256color"). Don't bother reporting problems where it
| isn't!
|
| > Outside, it should match your terminal: particularly, use
| "rxvt" for rxvt and derivatives.
| d4rkp4ttern wrote:
| I learned about Tmux just a few weeks ago and found out that one
| of the nifty features is that it is scriptable, I.e allows
| programmatically sending keystrokes to a specific pane. Then,
| inspired by some Japanese forums I asked myself if I can leverage
| this to have Claude Code actually interact with an interactive
| CLI script -- we know CC can launch a script via bash but if said
| script waits for user input then CC can't (easily) interact with
| it. Turns out yes we can leverage Tmux for this!
|
| So I used Claude Code to build a little el tool called Tmux-cli,
| which gives a convenient way to have CC (or any CLI coding agent
| for that matter) spawn a Tmux Pane, launch a script there, and
| actually interact with it.
|
| So it's like Playwright/Puppeteer for the terminal.
|
| You can get it via uv tool install claude-code-
| tools
|
| https://github.com/pchalasani/claude-code-tools
|
| There are some interesting possibilities this enables:
|
| Let CC autonomously test interactive CLI scripts, without me
| having to intervene and point out errors.
|
| Have the CLI coding agent launch UI from another pane and then
| use Puppeteer MCP to test from a browser.
|
| Let CC launch a cli script with a debugger enabled (e.g. Pdb) and
| set breakpoints etc -- for token-efficient code understanding,
| debugging and explaining.
|
| Let the CLI coding agent spawn and drive another instance of the
| same or other CLI coding agent, AND interact with it. Note this
| is way better than CC sub-agents which are "spawn and let go"
| black-boxes.
|
| I wonder if the discussed Tmux alternatives enable building this
| type of tool.
| Sherveen wrote:
| Yup, another fun thing to do w/ this: let Claude Code talk to
| and control Gemini CLI, OpenCode, other CC instances, etc. in
| interactive mode! A different flavor of subagent. :)
| d4rkp4ttern wrote:
| Indeed, or vice versa where we leverage Gemini's monster
| context length
| xrd wrote:
| Make sure you use the pipe operator.
|
| Very cool ideas in this thread.
| franktankbank wrote:
| Your scientists were so preoccupied with whether or not they
| could, they didn't stop to think if they should.
| d4rkp4ttern wrote:
| Nice. Had to look it up, didn't know it was a famous Jurassic
| Park quote, even though I did see it when it came out :)
| franktankbank wrote:
| Right back at you. I think its a pretty interesting
| application.
| blueflow wrote:
| > So it's like Playwright/Puppeteer for the terminal
|
| I mean, a tty is just a file descriptor... there have been
| script(1), expect(1) and chat(8) since the 80ies. tmux is not
| really necessary.
| woleium wrote:
| And screen(1) https://linux.die.net/man/1/screen
| AlecSchueler wrote:
| Don't forget tmux(1) https://github.com/tmux/tmux/wiki
| chrisweekly wrote:
| er, the context in this subthread is tmux alternatives
| AlecSchueler wrote:
| No, it wasn't, and I think you've missed the joke.
| 0x457 wrote:
| The context is "you don't need an entire terminal
| multiplexer such as Tmux when all you need is pseudo-
| tty".
|
| Bringing another terminal multiplexer isn't an
| alternative. In my agent, I use pseudo-tty without any
| tmuxes/screens.
| epr wrote:
| These are all great. If you need to do something more
| involved, pexpect is also worth mentioning. It's a
| reimplementation of expect in python that's easy to be
| productive with quickly.
|
| I used it in a previous job to automate configuring thousands
| of network devices
| anuramat wrote:
| "tmux capture-pane" strips escape sequences that break the
| terminal and sets all the right variables; try using expect
| with e.g. neovim
| barmic12 wrote:
| You right, it's pseudo terminal needed. The module pty of
| python can do this
| wild_egg wrote:
| Do you find the tmux-cli wrapper to improve results?
|
| I tell Claude to use the existing tmux CLI to send-keys,
| capture-pane, etc. and it works flawlessly. Literally just
| "never use the Bash tool, run all commands in tmux sessions"
| and it knows what to do from there.
| d4rkp4ttern wrote:
| This is nice to know. I didn't compare with plain Tmux but
| should. In Tmux-cli I set up some convenience functions and
| scaffolding to prevent accidentally killing itself etc. But
| yes if plain Tmux works well I would just use that; it's one
| less context burden.
| d4rkp4ttern wrote:
| One other thing I found is that when it spawns another Claude
| in a pane, and sends it a message, the enter key doesn't
| register if sent immediately, so the other Claude doesn't act
| on it. So in Tmux-cli I added a delay after experimenting
| with various values. I guess with plain Tmux it might run
| into this issue.
| Izkata wrote:
| > and found out that one of the nifty features is that it is
| scriptable, I.e allows programmatically sending keystrokes to a
| specific pane
|
| In case anyone was curious, screen can do this too with the
| command "stuff" (read it as the verb like "stuffing something
| into a box").
| benji-york wrote:
| If you're interested in doing similar things but with a
| terminal, the Kitty remote control mechanism is pretty cool:
| https://sw.kovidgoyal.net/kitty/remote-control/
| xrd wrote:
| I'm reviewing the docs and interested in the scripting. I
| like that it uses python to script.
|
| Could I have kitty send each line it receives to an external
| tool, say via HTTP?
|
| I want to make a custom frontend to claude code, or any other
| CLI tool, and an obvious easy frontend is a web tool that
| communicates over HTTP, so getting claude wrapped in a HTTP
| control system seems like a good starting point.
|
| I'm interested in whether things like "tmux capture-pane"
| which strips characters come from Kitty as well? Do I need to
| be cautious of control characters?
| aap_ wrote:
| Session persistence is the key feature for me. All the rest I
| don't need because i simply open more windows. However multiple
| windows (or whatever you call them) were really useful when I
| bought a vt100 as a teenager and programmed on that for a while
| for fun (with screen at the time, not tmux).
| wkat4242 wrote:
| > In summary: multiplexers add unnecessary overhead, suffer from
| a complexity cascade, because they actually have to translate
| escape codes, modifying them in hackish ways to get them to work
| with their concepts of windows/sessions.
|
| This is a feature for me. Because less and less applications
| bother supporting termcap, this way some applications can still
| work on my VT520.
|
| I don't really care what the kitty dev thinks anyway. He's
| entitled to his opinion but for me tmux is way more important.
| Also I think alacritty is better (though I generally just use
| Konsole).
|
| As a user I only care about what works well for me, not what's
| architecturally the most elegant solution.
| JdeBP wrote:
| You are very lucky to have a VT520. I have been idly on the
| look-out for a 525 for years, but not only are they
| inordinately expensive, the people selling them are not on the
| same continent as I am (and probably don't have my country's
| version of the LK).
|
| I've been on the lookout partly just to see whether this works
| properly with a genuine VT525:
|
| * https://jdebp.uk/Softwares/nosh/guide/commands/console-
| termi...
|
| Yes, should tmux ever go away, there's another option for
| transliterating terminal output of applications that just
| _expect_ all of the modern stuff with AIXTerm 's 16 colours and
| alternate screen buffers and mouse sequences and whatnot and do
| not check TERM properly. (-:
| NoGravitas wrote:
| My VT420 doesn't support hardware flow control, but software
| flow control does not play nice with many modern terminal
| applications. GNU Screen provides an extremely effective
| workaround, plus its other features. I've used tmux a lot on
| modern terminal emulators, but it seems to lack this important
| feature for vintage terminals. Glad that tmux solves your
| problems with broken apps that don't support termcap or
| terminfo.
| jelder wrote:
| This is written for the Linux-on-the-Desktop crowd, and good for
| them. But tmux really shines for folks using MacBooks with
| iTerm2. Its tmux integration is so good that it simply disappears
| into my workflow.
|
| With this in my `~/.ssh/config`, I can just type `ssh tmux` to
| get back to my remote dev box whenever I wake my computer or
| change connections. Host tmux
| HostName 1.2.3.4 IdentityFile ~/.ssh/etc.etc.etc
| RequestTTY force RemoteCommand tmux -CC new -A -s 0
|
| With iTerm2's tmux integration enabled, this will pop open a new
| window where the remote tmux tabs and scroll buffer look and act
| just like native, local iTerm2 tabs and scroll buffer. I don't
| even know any tmux commands.
| suslik wrote:
| Wow, I've tried tmux like a hundred times and could never learn
| to like it, falling back to screen and promising to myself -
| never again. I'm going to break my promise to try this.
| antonvs wrote:
| > falling back to screen
|
| So you're saying you're a masochist
| nolist_policy wrote:
| Isn't the screen equivalent literally this?
| Host tmux HostName 1.2.3.4 IdentityFile
| ~/.ssh/etc.etc.etc RequestTTY force
| RemoteCommand screen -dR
|
| Edit: I guess it's missing the iTerm integration
| fouc wrote:
| I've always found screen's ctrl-a is so much easier to reach
| for than tmux's ctrl-b. I recommend re-mapping ctrl-b to
| ctrl-a
| _kst_ wrote:
| I use Ctrl-Space. unbind-key C-b
| set -g prefix C-Space bind-key C-Space send-prefix
|
| I find it a lot easier to type than either Ctrl-A or
| Ctrl-B.
| cyberpunk wrote:
| The real superpower prefix key is ` especially if you
| have a british mac keyboard.
| __david__ wrote:
| Both C-a and C-b are so commonly used that I don't like
| either of them. I ended up going with C-\ since I only
| rarely use that one.
| anthk wrote:
| I just remapped the keys to ctrl-z after I swapped ctrl and
| caps lock. As you'd never suspend stuff under tmux for
| obvious reasons, you'll get the whole keyset for any
| cli/tui software.
| rcakebread wrote:
| I'll bite. What's so obvious? I suspend jobs in bash all
| the time while using tmux.
| anthk wrote:
| Often TMUX it's for tasks you woudn't suspend. And, if
| any, you can just use kill -STOP and kill -CONT among
| other signals from another tmux pane.
| mike-cardwell wrote:
| I use a combination of mosh and screen for this. I only need to
| type something to get my session back, after a reboot. Changing
| networks or putting my laptop to sleep for days doesn't drop my
| sessions: https://www.grepular.com/Immortal_SSH_Sessions
| ghkbrew wrote:
| Mosh looks very cool, though I've never used it. Does Screen
| provide some advantage over tmux in this setup?
| jvanderbot wrote:
| Yes. Mosh is a seamless replacement for ssh, and screen is
| a mostly seamless replacement for tmux. One more level is
| Mosh+byobu, which is so useful I don't even bother with
| plain terminals most the time.
| positr0n wrote:
| Haha I think you have the history backwards here. Tmux
| was created as a replacement for screen when it was 20
| years old! Speaking as someone with 'set -g prefix c-a'
| in their .tmux.conf because my muscle memory is so used
| to the screen hotkeys.
|
| GNU screen was released in 1987.
|
| tmux was created in 2007.
| lostdog wrote:
| Mosh does not support OSC52, so it's a barrier to getting
| copy/paste to work.
| brontitall wrote:
| On mobile so I'm not sure which case OSC52 applies to,
| but I use mosh+tmux 8-10 hours a day. Both bracketed
| paste and tmux selection setting local clipboard work
| fine
| radiofreeeuropa wrote:
| Mosh is excellent. It lets remote sessions survive (well,
| automatically and transparently recover from) disruption
| that reliably kills ssh.
|
| I basically don't use ssh at all any more for interactive
| sessions, because I'm sick of a few lost packets on wifi or
| a weak cell signal dropping my connections and forcing me
| to start over.
|
| Tmux, I used to use and eventually abandoned. I decided I
| didn't need _two_ keyboard-based window managers (I use
| Spectacle on Mac) and the one that was only for shells was
| the one that could go. I have replaced it with nothing, so
| far, aside from that I just open more Terminal.app windows
| now (I also used to use iTerm2, for years, until it dawned
| on me that I was using exactly nothing in it that 's not
| also provided by Terminal.app, and the latter's got better
| input latency, so I was suffering an extra installed
| program and slightly less responsive typing for no reason
| at all)
| crtasm wrote:
| Then a nice addition is to save typing it each time
| alias looptmux='while true; do ssh tmux; sleep 2; done'
| nolist_policy wrote:
| Better: autossh -M0 tmux
| aargh_aargh wrote:
| Does any Linux terminal have a comparable integration? I'm
| still using GNU Screen but willing to give tmux another shot.
| cpuguy83 wrote:
| Pretty sure iTerm is the only term that implements that tmux
| protocol.
| tristan957 wrote:
| Ghostty has infrastructure to support it from my
| understanding, like Mitchell did the initial plumbing. It
| just takes a spirited individual to finish it up.
| dizhn wrote:
| wezterm
| edoceo wrote:
| There was one called Terminator which had some tmux like
| features, split panes, broadcast, etc. It's not been
| maintained in a bit.
|
| https://gnome-terminator.org/
| rhesa wrote:
| I used to use terminator for a long time, but i've switched
| to tilix (https://gnunn1.github.io/tilix-web/) with little
| pain.
| felixding wrote:
| WezTerm
|
| The author of this feature also ported it to the Windows
| Terminal.
|
| Besides, Chrome OS's built in terminal also has tmux
| integration.
| natebc wrote:
| Do you have links to any examples? I've searched for this
| on and off for years, and i use Wezterm, but i've never
| been able to make it work like i remember the iTerm2
| integration working.
|
| Would love for examples using Windows Terminal as well.
| ho_schi wrote:
| I use happily GNU Screen. Keep it?
| scelerat wrote:
| I ran into so many little annoying color and font issues with
| vim, tmux and iTerm2 that I gave up on tmux (for local work).
| What small benefit I got from tmux on my local machine
| (basically surviving updates and a little more session
| persistence) I rarely miss.
|
| I wanted it to be better, and might go back if I could figure
| out the font issues, but I just don't have the time right now.
| op00to wrote:
| Would mosh stop you from having to reconnect to SSH at least
| after wake? You'd still need to reestablish a mosh connection
| after rebooting.
| paradox460 wrote:
| Tmux cc mode doesn't work over mosh. Something to do with how
| it mangles binary going over the wire. Breaks other iTerm2
| features like local copy paste from remote paste boards, drag
| and drop uploaf and download
| alexozer wrote:
| Wow, I was wondering if e.g. Ghostty could implement something
| like this but that's cool it's already proven out.
|
| Does everything still go "through" tmux (so parsing etc. is
| still done twice), or does iTerm handle most of the rendering
| and just delegate scrollback storage/session persistence to
| tmux? The latter seems like the best of both worlds.
| gorjusborg wrote:
| Composing simpler tools works better than complicated tools
| that try to solve everything.
|
| I am a former Kitty user and current Ghostty user and hope
| Ghostty stays basic and good.
| jayknight wrote:
| I've just now learned about tmux's control mode. Can you
| explain what that tmux -CC command does? I use `ssh -t <host>
| tmux attach -d` from bash history to (re)establish my remote
| tmux session. `new -A -s 0` would do the about same thing, I
| just don't see how -CC is supposed to work here.
|
| Edit: It appears to be related to iterm2's tmux integration.
| Neat.
| canistel wrote:
| From what I have seen, tmux is the _only_ multiplexer with with
| you can select from the scroll-back buffer using only the
| keyboard (without using the mouse).
| meitham wrote:
| Absolutely! You also have full control over the history size,
| along with powerful search capabilities. You can move panes and
| windows seamlessly across sessions, and even share those
| sessions with other users. My yank script integrates with tmux
| buffers, so copy/paste works flawlessly, even in vertical
| splits. I strongly disagree with the article; I simply can't
| imagine using a terminal without tmux.
| magarnicle wrote:
| Do you mean select into the clipboard?
| canistel wrote:
| To tmux's clipboard and if required to the system clipboard
| too...
|
| set -s copy-command 'xsel -i'
| jmholla wrote:
| screen does as well. Unless I'm missing something here.
| charlie-83 wrote:
| I think a key piece of context to Kovid's distain of tmux is how
| good window management is in kitty. I regularly have at least ten
| terminals open and navigating them is a breeze. I previously
| lived in tmux but much prefer this.
|
| The session persistence thing is still best solved with tmux,
| however, I don't ever need this. Nohup is sufficient for long
| running commands where my ssh might fail. I don't really find
| myself sshing into a machine and then setting loads of env vars
| that I need to persist.
| jon-wood wrote:
| More generally I use a tiling window manager which is already
| doing pane/tab layout for me, but doing that with every window
| I have, so I don't really want tmux acting as a separate window
| manager just for shells.
| gchamonlive wrote:
| For long running sessions I think screen is better... `nohup
| cmd &` is finnicky and I don't trust it to work on every
| software. I think `screen -S foo` and `screen -r foo` is much
| more ergonomic. No pipe to file, no disowned pid.
| em-bee wrote:
| i tried using kitty a year ago. i was not impressed:
| https://news.ycombinator.com/item?id=40478732
|
| kovid is talking about how tmux gets in the way of terminals
| adding new features. i agree with that, but what about the
| features that tmux offers that i have yet to see in any gui
| terminal. (multiple sessions. the ability to connect to the
| same session from multiple terminals. scriptability, including
| sending characters into a terminal. splitting windows into
| multiple panes...)
|
| can kitty do any of those? if you want to add features to the
| terminal, then you have to content that tmux does as well, and
| maybe tmux features are more interesting to me than kittys. so
| if you want to win me over, then you have to actually implement
| some of the features of tmux that i use.
|
| (watching the interview, it looks like kitty does indeed
| implement some of tmux features, because interestingly the
| interviewer asks just the right questions. but i need to look
| for a more comprehensive introduction to see how kitty can
| replace tmux locally.)
| metaltyphoon wrote:
| It seems that WezTerm can do what you asked
| em-bee wrote:
| all right, a year ago i tried kitty:
| https://news.ycombinator.com/item?id=40478732 maybe it's
| time to try wezterm now:
|
| first impression: dark background. no good. i want light.
| no gui to change. now where is that theme setting? ah,
| here: https://wezterm.org/config/appearance.html there are
| 1000 color schemes available! wut? ok, this seems to be all
| i am looking for: https://wezterm.org/config/lua/wezterm.gu
| i/get_appearance.ht... gee, that's a lot of code for a
| single setting.
|
| ok, that's better. now let's explore how wezterm handles
| sessions and windows/tabs.
|
| it seems sessions would be domains, and so for a bunch of
| local sessions i need to configure some unix domains:
| https://wezterm.org/multiplexing.html#unix-domains
|
| there is more about sessions here:
| https://wezterm.org/recipes/workspaces.html but it's all
| very abstract.
|
| and where does this stuff go? ah, here:
| https://wezterm.org/config/files.html
|
| turns out that the config example for the color scheme
| conflicts with setting other config values. i need
| config.color_scheme = ... return config
| not return { color_scheme = ... }
|
| that could have been explained better.
|
| and finally, how do i switch sessions or tabs? no word
| about that on the multiplex page. or elsewhere.
|
| fortunately, i found this article which describe an
| elaborate setup to make wezterm behave somewhat like tmux,
| with familiar keybindings. maybe i can get this to work:
| https://mwop.net/blog/2024-07-04-how-i-use-wezterm.html
|
| oh, one last issue: there are no resize handles, or a
| titlebar, although according to the descriptions they
| should be there. where did they go?
| Myrmornis wrote:
| If I were to stop using tmux, the things I would need to replace
| are:
|
| 1. zoom-pane (temporarily make one pane be the only pane) (also
| can someone please add this to vscode!)
|
| 2. keybindings to navigate focus between panes according to their
| layout positions
|
| 3. ability for another process to programmatically change which
| terminal window has focus, and window naming
|
| I think that's it. Could probably hack most/all of that together
| with hammerspoon I guess. I don't use it for persistence, and I
| certainly don't like the scrollback UX. It has got in the way
| from time to time, principally with its slow adoption of
| hyperlinks. But I'm general it's been a huge win for years.
| sabellito wrote:
| 1. workbench.action.toggleMaximizedPanel
| matthieucan wrote:
| Have you tried "View: Toggle Maximize Editor Group" in VS Code?
| In my setup, it does roughly the same thing as with a tmux
| pane.
| nickjj wrote:
| I still plan to keep using tmux. I like how it manages multiple
| sessions, making it easy to switch between projects and even
| resurrect them after rebooting. I also never had a problem with
| mouse copy / paste using tmux-yank. I've been using this set up
| for many years.
|
| One cool feature of tmux is its ability to send keys. I did that
| a few months ago when I was revamping my dotfiles. I kept
| changing aliases and other shell files and wanted to source those
| files in dozens of panes at once and also reload neovim when I
| changed certain config files.
|
| The above was pretty easy to pull off using a combo of tmux's
| built-in commands and a shell script. I made a post and video
| about that here: https://nickjanetakis.com/blog/running-commands-
| in-all-tmux-...
| aragilar wrote:
| It's a bit unclear what the limitations of the non-screen/tmux
| alternatives are E.g. how does the scrollback work if I were to
| disconnect and then reconnect with a different machine, can I
| view the scrollback like screen/tmux?
|
| It's also nice to be able to re-connect and be able to resume a
| session without having to reopen many terminals, which you would
| lose with the lack of window management.
| sevensor wrote:
| Kitty is great; I want to see it succeed in pushing terminal
| emulators forward into the current millennium. However, I can't
| use kitty at work, and I absolutely live inside of tmux. The
| server is where all the action is, and when I get disconnected, I
| want to be able to pick things up exactly where I left them.
| Window layout, the state of each shell and text editor, what's in
| the copy buffer, scrollback, everything. I can't give that up
| unless I have a suitable replacement on Windows. Until then I
| will continue to use tmux at work and kitty at home.
| gorjusborg wrote:
| I used Kitty for a while. I was impressed that I could recreate
| my tmux config pretty closely.
|
| I went back to tmux and basic terminal because it works
| everywhere, and composing tools is just more durable overall.
| em-bee wrote:
| how do you do something like tmux sessions (not just windows)
| in kitty? how does switching sessions and windows work? can i
| connect to the same session in multiple windows? or can i
| manage separate windows with different sets of sessions?
| submeta wrote:
| I love tmux in combination with tmuxinator. Because with one
| command I can start my dev setup with one split for nvim, one for
| lazygit, one for yazi and one for claude code. In another window
| I can run the server, in another I can tail the logfiles.
|
| I have similar setups for various projetcts and do not need to
| manually start services, tools, whatnot. With `mx projectx`
| everything is started within seconds.
|
| And navigating panes and windows is super easy with the proper
| shortcuts (opt+h,j,k,l), even across tmux and nvim.
|
| Why would I give up on that?
| timeforcomputer wrote:
| Thanks for the link to tmuxinator, I had heard of it but never
| learned what it does. I think I'd like something like this. But
| I think this is a case of tmux providing a platform, I think
| the core idea of tmuxinator could be implemented outside of
| tmux, so tmux in that regard is basically an implementation
| detail.
|
| Then it is a pragmatic decision, using tmux you get to use the
| ecosystem of things like tmuxinator which explicitly target
| tmux to get a known number of terminal features like splits.
| What I learn from the OP, is that there are technical reasons
| that tmux is not a "good design" - like Kovid's comments on how
| it constrains innovation in terminal designs - which might lead
| someone to consider, what actually does tmux do and could my
| workflow be implemented otherwise?
|
| It might be a bunch of unixy hacks and tricks (as another
| commenter here said) but it can work. I'd imagine recreating
| something like tmuxinator would be hard though, but it could
| also be interesting, like having arbitrary GUI programs
| configured to appear in "splits" using tiling integrated
| seamlessly within the terminals. But yeah, if the workflow is
| already set up and serviceable and supported with a community,
| using tmux, then I'd just keep using it.
| zettabomb wrote:
| The conclusion I come to from this is that yes, I actually do
| need tmux, as the alternatives proposed are far more annoying and
| provide no benefit. I don't have a need for graphics in the
| terminal, and frankly I find it odd that we wouldn't simply
| display graphics... with the graphics system. But I do have a
| need for seamless session persistence and multiple terminals, and
| I do enjoy splitting a window when I'm running a command on
| multiple servers.
| c120 wrote:
| I need "tmux" on remote linux machines that don't allow me to
| install "screen". If there's an easier way to keep a session
| running (and interactive) over internet disconnects, I have not
| found it yet
| zeendo wrote:
| If you can't install screen then I'm surprised you can install
| tmux - BUT if you can install wezterm then it solves this need
| nicely by adding sessions + multiplexing to the terminal
| emulator itself.
|
| https://wezterm.org/multiplexing.html
| nobleach wrote:
| Honestly, my only gripes with TMUX have been:
|
| 1. Having to zoom a window before copying multiple lines of text
| (Kovid brought this up in the interview that was mentioned in
| this article)
|
| 2. The weirdness of copying text from the scrollback buffer into
| the clipboard
|
| I've tried so many things for the second one over the years. I
| think I have it working okay-ish these days. But there are still
| plenty of times that I say, "aw screw it", and literally use the
| terminal's copy command.
|
| Every other solution to my multi-terminal workflow have been
| worse though! i3/bspwm with multiple terminals were okay. It was
| just hard to have "projects". I'd have to visit each terminal and
| switch to the proper directory, launch servers/docker-
| compose/etc.
|
| Zellij felt like too much "hopping out into manipulation mode,
| manipulating, then hopping back into work mode". Those
| milleseconds were enough to halt my flowstate.
|
| Single terminal with built-in tabs/splits felt clunky as I
| couldn't get the keyboard shortcuts into muscle memory (perhaps
| more time would help)
| gempir wrote:
| Tmux prevents vendor lock-in but on Terminal level. It's so
| established and standard that everyone knows they need to support
| it, which is great. I don't need my terminal do display pictures,
| render video or whatever crazy features they come up with next, I
| want a solid base with the essentials.
|
| The rest the Operating system applications can probably do better
| anyway. VLC, MPV, Apple Preview IrfanView etc.
|
| That's why I love Alacritty, no fuss, no overcomplication. The
| basics, fast and stable.
| jdbernard wrote:
| I don't use tmux because I _have_ to. I use it because I love the
| way it works. The issues the author of the article and Kovid
| Goyal raise are not issues for me in practice. If something is
| built that better suits my needs, I 'll be happy to switch. I am
| particularly sympathetic to Goyal's gripes about the
| performance/resource wastes of a multiplexer.
|
| But I also take issue with statements like "terminal multiplexers
| are a bad idea, do not use them, if at all possible" (from the
| kitty FAQ and the YouTube video linked in the article). Tmux
| solves a number of real problems for me that Kitty doesn't. Kitty
| also seems to be moving in a direction that I am not interested
| in. It's tied to a windowing system when I want a terminal that I
| can use headless. Even with the hacky workarounds the article
| mentions, it doesn't really support session persistence when I
| use this feature of tmux weekly. It introduces a lot of features
| that are likely to lead to visual noise when the constraints of
| text-only are one of the main reasons I like terminals
| (personally I _don 't want_ images in my terminal, full stop).
|
| Now, all of this is fine. It's the other statement, "[tmux acts]
| as a drag on the ecosystem as a whole, making it very hard to get
| any new features," that causes it all to rub me the wrong way.
| The only reason you feel like tmux acts like a drag is because
| there are users like me who won't switch to something like Kitty
| if it doesn't support tmux. So don't worry about us. Build a new
| thing that is not backwards compatible and live with the fact
| that many people won't use it. If you really want to drive the
| ecosystem forward as a whole, be less condescending about real
| use-cases that bring benefit to real users.
|
| To be clear (because text is a limited medium), I'm not grumpy,
| angry, or against Kitty because of this. But I am dismissive.
| FergusArgyll wrote:
| > Another example is buffer scrollback. It's one of those things
| where you have to learn the tmux way of scrolling a window. You
| get used to it, of course, but it's just not great.
| And what about mouse select to copy/paste? It works most of the
| time, but sometimes tmux gets ignored and I'm selecting
| across splits which makes the thing I'm copying impossible
| to grab without bailing.
|
| funny, those things make me use tmux! My 2nd laptop is a debian
| terminal-only laptop (it's very old), the mouse doesn't work so
| the only way to copy paste _is_ tmux (or screen probably but I
| never learned it) For me, tmux is not replaceable
| prmoustache wrote:
| I am regularly using waypipe to use a remote kitty terminal.
| tpoacher wrote:
| Don't use tmux. Use a nice wrapper for tmux instead (e.g. like
| byobu).
|
| Otherwise complaining about tmux and talking about hacky
| workaround alternatives is a bit like complaining about the
| internet and advocating for the telegraph as a hacky alternative
| because you don't like writing your own HTTP requests by hand and
| morse code is so much simpler.
|
| Having said that, if really all you want is pane splits / window
| management, lots of terminals have their own solutions for this.
| Guake is a good one.
|
| disclaimer: I use Guake and still prefer to just use tmux (byobu)
| from Guake
| em-bee wrote:
| does guake support multiple sessions? remembering window layout
| through restart? or easily configurable startup layout?
| scudsworth wrote:
| very interesting. im going to continue using tmux instead of
| doing any of that.
| jollyllama wrote:
| You lost me at nohup.
| sbinnee wrote:
| My fingers are just too used to tmux and I can do all I want to
| do. But I hear the scroll issue. When I have to copy multiple
| chunks, I have to go to cp mode visual a chunk and as soon as I
| enter tmux goes to the bottom line and I have to scroll up
| again...
| finaard wrote:
| If you're using kitty and have terminal related problems the
| easiest solution usually is just not using kitty.
| GNOMES wrote:
| I have been tempted to drop tmux locally for native Ghostty
| panes/tabs, but I prefer the single height tmux status bar with
| window list only (set -g status-left '' + set -g status-right '')
| vs the thicker window decorations using macos-titlebar-style =
| tabs.
|
| I did come up with Ghostty bindings to replicate my tmux settings
| if it helps anyone (my tmux leader is ctrl + space):
| # clear default bindings + add paste back keybind=clear
| keybind=super+v=paste_from_clipboard # navigate
| panes keybind=ctrl+h=goto_split:left
| keybind=ctrl+j=goto_split:bottom
| keybind=ctrl+k=goto_split:top
| keybind=ctrl+l=goto_split:right
| keybind=ctrl+space>shift+apostrophe=new_split:down
| keybind=ctrl+space>shift+five=new_split:right
| keybind=ctrl+space>space=equalize_splits
| keybind=ctrl+space>z=toggle_split_zoom # navigate
| tabs keybind=ctrl+space>c=new_tab
| keybind=ctrl+space>one=goto_tab:1 ...
| keybind=ctrl+space>zero=goto_tab:10
| radicality wrote:
| Nice, I came up with something similar when trying ghostty.
| Were you able to replicate/setup continuous key hold for
| resizing? The way I have it it tmux is that doing
| leader,Shift+hold h/i/k/j continually resizes a pane while I
| keep holding for example Shift+h. But I wasn't able to
| replicate it in ghostty
| GNOMES wrote:
| Never realized you can do that. Can you share that tmux
| binding? Right now I use `bind -r Space next-layout` for
| resizing (spam repeatedly).
| tiffanyh wrote:
| Reminder: terminal multiplexers (like TMUX, Zellij, and Screen)
| are terminals too -- even if often overlooked as such.
|
| So, if your multiplexer lacks support for certain features, it
| will limit functionality in advanced terminals like Kitty or
| Ghostty.
| dankobgd wrote:
| I don't need much. I tried zellij but i couldn't stick with it. I
| either had to lock/unlock or change keybinds which is also
| annoying. Now i use ghostty and i can create new splits, tabs and
| i know few shortcuts to move around and resize and that's it.
| imcritic wrote:
| But Zellij supports tmux hotkeys.
| yoyohello13 wrote:
| Zellij now has a mode that uses a leader key style. So no need
| to lock/unlock.
| jrm4 wrote:
| Obviously, different ways for different folks -- I never got into
| tmux, but perhaps relatedly, what I want is a well thought out
| and stable terminal/GUI filemanager hybrid thing; e.g. I can
| either "cd" or just click where I want to go, etc. I've seen half
| done implementations of this but nothing comprehensive?
| layer8 wrote:
| What would happen when you click on a directory (I'm assuming
| you're imagining a directory tree on the side in a separate
| pane) while some CLI program is running? Run the corresponding
| _cd_ when the program exits and returns to the shell?
| jrm4 wrote:
| Yes, but I'm imagining that this isn't something that works
| in conjunction with another terminal program, but that it's
| one program -- some kind of shell/GUI hybrid.
|
| I have actually seen this before, in the very fun but silly
| and not-particularly-useful edex-ui thing. (great way to
| impress people who don't know, but like, if you type your
| password in it it literally shows the keystrokes)
|
| https://github.com/GitSquared/edex-ui
| t_mahmood wrote:
| Why would one go through so much trouble when you have tmux?
|
| But I really want Vim to color properly in it, can anyone give me
| the right solution?
| homebrewer wrote:
| Have you tried setting 'termguicolors' in vimrc?
|
| https://vim-jp.org/vimdoc-en/options.html#'termguicolors'
| ninetyninenine wrote:
| I was in the same boat then I discovered this thing called a GUI
| and inside this GUI I could use this thing called tabs. It was
| revolutionary technology.
|
| It's just too bad I suffer from a lack of common sense and
| insistence on trying to believe that all archaic terminal text
| based tools are better than anything else. I'm a developer and
| developers have insight on the best UI and we know that terminals
| are better than anything in the known universe. If you use a
| mouse you're an ass hole.
| z0r wrote:
| I too also don't understand other people's workflows but
| believe I know the best way to interact with a computer.
| ninetyninenine wrote:
| Agreed. Stupid people with stupid opinions don't exist.
| Everyone's opinion is valid. We must be inclusive of people
| with bad and wrong ideas. All criticism is wrong because
| saying someone's workflow isn't good will hurt their
| feelings.
|
| Useful debate on the merits of anything is a pointless
| endeavor because all varying opinions are valid. There is no
| best, better or worse... just everyone's freedom of opinions.
|
| In my opinion eating lead is good for you and using a mouse
| and clicking on tabs hinders my efficiency by 300 percent.
| That's my opinion! And it's valid! I am valid!
| em-bee wrote:
| not appreciating the snark. tmux does way more than being an
| alternative way to get tabs.
| ninetyninenine wrote:
| Ok. No snark. Sessions, tabs, windows, tiling . All done in
| GUIs and done better.
|
| Tmux is good when you have no gui.
|
| But all this endless getting square pegs to fit in a round
| hole is what causes the snarks. Like you want to draw
| windows? Let's use terminal characters instead of lines!
| Makes perfect sense.
|
| I find it incredulous that a lecture had to get this guy to
| realize what's wrong with tmux and he still doesn't see that
| this problem can be avoided by using a gui. He still goes for
| terminal abstractions.
|
| GUI is an obvious solution. But this guy is blind.
| devnullbrain wrote:
| > Sessions, tabs, windows, tiling . All done in GUIs and
| done better.
|
| Sorry but no, _really_ no.
|
| Windows:
|
| - Has two ways of swapping between windows, taking up 2/3
| of my modifier keys for use with Tab
|
| - Loves to offset windows by one pixel and resize my
| taskbar
|
| - Irrevocably moves things around if I disconnect a monitor
|
| - Flashes taskbar icons constantly, like a particularly
| badly behaved terminal bell
|
| and Mac:
|
| - Leaves zombie processes in the cmd-tab list
|
| - Is philosophically incompatible with any kind of
| fullscreen workflow.
|
| Both have:
|
| - Slow animations for basic windowing
|
| - Only a few tiling options
|
| - Minimal configurability...
|
| - ...which doesn't matter anyway, because if someone at HQ
| gets bored, you're getting a UI interface redesign that's
| incompatible with your current workflow
|
| - An approach to tab dragging that induces seizuring
| windows, because things are just too slow and fickle
|
| - The ability for anything to steal my focus, mid-typing
|
| But what's most damning of all is that both have a wealth
| of popular tools written and used by people trying to
| wrangle them into something useable.
|
| There is nothing I could do to make them as fast to use as
| my tmux based workflow, simply because they do not work
| quickly enough for the keypresses I'm entering and don't
| even appear to be deterministic.
| ninetyninenine wrote:
| Use different apps. Don't have to stick with the default
| OS window primitives. omfg. I use loop for macos.
|
| So for some reason a terminal app where you can't even
| draw a proper line vertically across the screen...
| somehow the people who make apps for terminal are
| geniuses in making windowing UIs, more genius then people
| who want to work in pixels. I don't understand why.
|
| And these complete geniuses are like, NO! I don't want to
| work with pixels. I want to use ascii characters to draw
| stuff that ONLY looks sort of like boxes, because that's
| the smarter thing to do!
|
| And don't get me started on config files. What's better,
| a menu where I'm presented with all my options? Or a
| freaking config file where none of the options are
| presented and I have to look it up in a man page and then
| if I make a typo often it doesn't tell me there's a
| problem.
|
| And likely you aren't even using that terminal app in a
| proper terminal. You're emulating a terminal underneath a
| GUI which is a huge performance penalty. Modern OS's
| present to you an advanced interface, but you're too
| elite to use it, so you EMULATE a primitive interface
| underneath the advanced interface.
|
| Bro use linux and uninstall gnome or KDE. Throw that
| mouse into the trash. That's the common sense future of
| UI according to you?
| em-bee wrote:
| _a freaking config file where none of the options are
| presented and I have to look it up in a man page_
|
| oh the irony. because that is what wezterm and kitty make
| me go through. i'll have a report soon.
|
| EDIT: here is the report:
| https://news.ycombinator.com/item?id=44762241
|
| that wezterm config file is a monster. all that, just to
| have tmux like functionality. well, at least it is
| possible. that's a massive step forward.
| devnullbrain wrote:
| >What's better, a menu where I'm presented with all my
| options?
|
| You get neither
| em-bee wrote:
| _No snark_
|
| thank you. that helps.
|
| _All done in GUIs and done better_
|
| could be done, and i agree. but i have yet to find a
| terminal GUI that actually does.
|
| tmux has a great and useful TUI. all the terminals i have
| tried so far, have a very minimal GUI. they have tabs, and
| some have panes that's about it. tmux works out of the box
| without any configuration at all. i can just build up my
| sessions interactively. i evaluated kitty a year ago, and i
| am testing wezterm now. neither are usable without having
| to manually write an elaborate config file, and neither
| include all the features that tmux has.
|
| i would love to find a GUI terminal to replace tmux. but
| there isn't one yet. at least it looks like both wezterm
| and kitty are working on it. so maybe in a year or two
| there will be something that can actually compete with
| tmux. but until then it's just a wish.
| ninetyninenine wrote:
| Get rid of terminal all together. That's the angle I'm
| coming from. Problem solved.
| em-bee wrote:
| well that's even worse, i mean in terms of what GUIs so
| far have achieved. a GUI that is capable of replacing the
| commandline has not been built yet.
| aidenn0 wrote:
| [edit]
|
| The below is fixed (https://github.com/shell-
| pool/shpool/pull/213/files) upstream already, but is pending a
| release.
|
| I never heard of shpool, so just tried it. shpool completely
| breaks my PROMPT_COMMAND because it assumes that each word (in
| the shell sense) is a separate command. My PROMPT_COMMAND
| included "history -a" thus causing it to run "history" and "-a"
| on every prompt, making things quite unusable.
|
| It's quite maddening because all they had to do was write a lot
| _less_ code to fix it: eval
| "${SHPOOL__OLD_PROMPT_COMMAND}"
|
| Would run the old prompt command just nicely instead of the much
| longer: for prompt_hook in
| ${SHPOOL__OLD_PROMPT_COMMAND}; do
| ${prompt_hook}; done;
| yoyohello13 wrote:
| I highly recommend zellij if you're looking for a newer
| multiplexer. It give a bunch of tmux features but without some of
| the legacy baggage.
| eawgewag wrote:
| I only use tmux for one reason -- for a script that setups my
| local server and runs backend/frontend/etc
|
| If there's a better way, I'm open to it. As of right now Claude
| can't vibe code me a script that opens two ghostty tabs, so tmux
| it is
| deadbabe wrote:
| If I could just figure out how to scrollback in ghostty I
| probably wouldn't bother with tmux.
| jauntywundrkind wrote:
| Tmux has definitely caused me some pain too. I'm mostly back now
| (semi alas) but for a while I was using shpool adjacent dtach to
| leave nvim sessions running even if I logout. If I was doing
| things on the terminal, it would be inside an nvim terminal
| window.
|
| My workflow is project oriented, and I have to juggle multiple
| projects. So I wrote a small script to let me quickly either
| attach to an existing dtach session for a project by name, or to
| start a dtach+nvim session for a project.
|
| Also included some fun wildcarding, so I didn't have to type the
| full name of the project out, could just type some letters and
| hit enter.
|
| https://github.com/jauntywunderkind/dtachment
|
| I don't see change as likely, but it does strike me as absurd
| that although I had gotten rid of tmux as a redundant window
| management system, I still had both the OS and nvim's window
| management going. The author talks about how things would work
| over ssh, but ideally to me, I could ssh in, forward some ports,
| and start some new terminal emulators that open multiple nvim
| clients that attach to a persistent perhaps headless nvim
| session.
| cogman10 wrote:
| I'm by no means a tmux power user, but it does have really nice
| features for when I need it.
|
| The primary usecase I've had for it is I can kick off 1 or
| multiple long running jobs, exit, and then come back later and
| checkout the various stdout logs to see how it worked.
|
| Could I accomplish the same thing with a bunch of stdout pipes,
| disown, fg, ctrl-z, etc? Sure. However, tmux makes it really easy
| to do that and then quickly switch around sessions to see how
| things are going.
|
| In the simplest workflow, it looks like this
| tmux longcommand() ctrl + B D
|
| and later tmux -a
|
| to checkout and see what's gone on with the command long after I
| disconnected with ssh.
| ziml77 wrote:
| I think it's good practice to always start tmux immediately
| after opening an SSH connection. You might not know a command
| is long-running until after you start it. And you never know
| when you connection will just randomly drop. If you're using
| tmux it's never a big deal when that happens.
| bitbasher wrote:
| This blog post reminds me of _why_ I use tmux. Did you see how
| much they needed to do to even resemble the workflow of tmux?
| Jeez, just use tmux. I don't mind dealing with wonky copy and
| paste once in a while.
|
| > In summary: multiplexers add unnecessary overhead, suffer from
| a complexity cascade, because they actually have to translate
| escape codes, modifying them in hackish ways to get them to work
| with their concepts of windows/sessions.
|
| What does that have to do with you using tmux? You're not the one
| maintaining tmux's codebase.
| Skunkleton wrote:
| > I don't mind dealing with wonky copy and paste once in a
| while.
|
| This problem is in no way unique to tmux. You have the same
| problem with any terminal app that takes over drawing, eg vim.
| That said it is also easy enough to fix.
|
| The solution is OSC52, a terminal escape sequence that the
| emulator can use to interact with the system clipboard (kitty,
| alacritty, iterm2 all support this). The first step is to get
| you a script that writes out data in that protocol. Its easy
| enough: #!/usr/bin/env python3 import
| os, base64, sys clip =
| base64.b64encode(sys.stdin.buffer.read()) for pid in
| (os.getpid(), os.getppid()): # so that osc52-copy can be
| invoked by processes that themselves do not have a tty.
| cty = f"/proc/{pid}/fd/1" try: fd =
| os.open(cty, os.O_WRONLY) if os.isatty(fd):
| os.write(fd, b'\x1b]52;c;') # the actual escape sequence
| os.write(fd, clip) os.write(fd, b'\a')
| break except: continue
| finally: os.close(fd) else:
| raise SystemExit(f"no tty")
|
| Now you can do this:
|
| $ grep my_thing < some.txt | osc52-copy
|
| And whatever got into osc52 is now on your system clipboard.
|
| Tmux (set -g clipboard on) and nvim (unset clipboard) both have
| native osc52 support, and the script above can be used to
| integrate other places.
| tristan957 wrote:
| What is the benefit of this over pbcopy and wl-copy?
| larntz wrote:
| If you're working locally I can't think of much. OSC52
| works to copy to your local clipboard from a remote system
| (e.g., over ssh) from within tmux or nvim as long as you
| are using a terminal that supports it.
|
| I use it to copy from remote system when I'm in nvim
| (`"+y`).
|
| Here are a couple links that relate to tmux and nvim.
|
| - tmux: https://github.com/tmux/tmux/wiki/Clipboard
|
| - nvim: https://neovim.io/doc/user/provider.html#clipboard-
| osc52
| bitbasher wrote:
| I generally use xclip to copy program output. It has been
| around forever. Otherwise, I pipe into vim or I'm already
| using vim and I can copy via visual mode with "+y
| carodgers wrote:
| Terminal emulators have taken a very odd attitude toward
| OSC52. Many (or all?) of them selectively disable either
| copy, or paste, or both, depending on how cautious the
| maintainer is.
|
| Yes, it's true that an application that can read system
| clipboard content may scrape a password, but literally any
| application running in the terminal can read private keys out
| of your .ssh folder.
|
| With some heavy reading and a bit of experimentation, you can
| usually get this working, though.
| udev4096 wrote:
| I am tired of seeing people creating problems out of nowhere.
| The reasons author gave are stupid and I am gonna question his
| "7+ years" of tmux usage
| gloomyday wrote:
| I think some people should just admit they love tinkering
| with their tools instead of saying it is for productivity or
| whatever.
| hollowonepl wrote:
| I just browsed through to realize that this is not criticism to
| tmux very existence. It's just author found his own ways. That's
| OK. I was once screen user, tmux extends that, but comes with
| emacs keyboard combos like if I was doing Mortal Kombat fatality
| trick for a simple thing and I personally found zellij more user
| friendly to me, unless I launch my linux box with i3 where all
| that is basically replaced by a quite interesting compositor.
| Point is... there are many ways to solve a problem... finding one
| that works for an individual doesn't automatically create
| religious dogma... unless one wants to be internet famous for 72h
| and then forgotten until another dopamine shot hits.
| skeptrune wrote:
| This sounds strictly more complicated than just using tmux.
| anthk wrote:
| TMUX supports sixels just fine. It's a damn standard, and you
| have it at OpenBSD's base. Keep It Simple, Stupid.
|
| Also, tmux new-window does wonders with software spawned from
| sfeed, sacc and who knows how many TUI/CLI tools.
|
| You open your RSS feed list with sfeed, read the whole page with
| C under 'less', and if there are images, you can spawn Links in
| another page with 'o'.
| elzbardico wrote:
| All good points relating to friction points with tmux.
|
| But, I am not an uber-elite-geek and Zellij is a good enough
| compromise to me.
|
| It gives me the things I am too lazy to solve by myself like
| tmux, with a lot less pain points.
| ho_schi wrote:
| I keep using _GNU Screen_ * Scrolling on TTY
| (Linux itself doesn't support this for some years) *
| Window-Tabs on TTY, Wayland, SSH * Sessions *
| Copy/Paste
|
| I'm not using ZelliJ or Tmux because I don't need more features
| and I know the shortcuts. I'm fine and don't need weird
| workarounds. This article even confirms my decision!
|
| Would love some good C developers helping the Screen people.
| slim wrote:
| If your main issue is session persistance you should try using
| mosh
| em-bee wrote:
| mosh doesn't allow you to reconnect to an old session if you
| restart the client or connect with a different one. tmux/screen
| do.
| samgranieri wrote:
| I've migrated from tmux to zellij. And I'm playing around with
| omarchy and am really digging the tiling window manager feature
| f4ce63f3 wrote:
| Are you serious?
|
| Press "<Enter>~." into your ssh window.
|
| Do you think ssh isn't interpreting escape codes either for some
| reason?
| 5pl1n73r wrote:
| > Further, I'm slowly noticing things that tmux didn't handle
| well, but now, "just work": native scrollback, terminal
| notifications, and terminal titles being the most notable
| changes.
|
| You can make tmux's OS window title and its internal window
| titles be whatever you want:
|
| Add "set -g set-titles" to ~/.tmux.conf. To test without changing
| the config, type `^B : set -g set-titles`, and to restore it back
| to default, `^B : set -gu set-titles`. This will be useful but
| overly verbose. It can be configured further. For example, `set
| -g set-titles-string "tmux | #{pane_title}"` will make it contain
| the title set by the shell (for PS1, I just make it set the
| current directory with `\w` or `\W`).
|
| Then, to make tmux's window titles (so, what will show up in the
| "window list") also be named after the current directory, you can
| use `set -g automatic-rename-format "#{pane_title}"`.
| NoSalt wrote:
| I host a Minecraft server at my house; tmux is great for this:
|
| 1. Log in to the physical server.
|
| 2. Start a named tmux session.
|
| 3. Run the Minecraft start script (log messages start populating)
|
| 4. Ctrl + b ... d
|
| Now, whenever I need to do something with the server, I just
| attach back to the session and do it.
| lou1306 wrote:
| > "You might not need tmux"
|
| First step, reimplementing the (arguably) one essential thing
| tmux provides, i.e., persistence: all tools have "varying degrees
| of success" and "are buggy". Scrollback? In tmux you "have to
| learn the tmux way", with the alternatives you _might_ have it if
| you 're lucky.
|
| I went into the post with an open mind but I don't think I will
| be ditching tmux anytime soon...
___________________________________________________________________
(page generated 2025-08-01 23:01 UTC)