Tmux has forever changed the way I write code [video] | Hacker News Reader

Tmux has forever changed the way I write code [video]

youtube.com

116 pointsgoplayoutside88 comments

the author goes in details on why tmux is great, which it is, but fails to mention it's greatest feature: send-keys.

I can have my code in pane 0 and my code console running a shell in pane 1, and simply use the send-keys command to execute the selected code (or line) instantly in pane 1.

I use this command more than 100 times per day.

Interesting. Is it for testing out parts of a shell script or does it have more uses?

not just a shell script. Any code.

I could have a rails console running below in a pane and send rails code directly from the file above.

Works with anything

I find it incredibly useful for iterating on SQL queries. Write a query, send to the database, examine the result, tweak the query a little, go around again.

I just use that feature in IDE...

Useful for executable documentation or runbooks, whatever you call the next level above scripts. You check your scripts into source control but how do you invoke the script? Copy and paste the example? Type it by hand every time? There's no need to copy-paste from a README into a terminal when you can "send" it.

>simply use the send-keys command to execute the selected code (or line) instantly in pane 1.

Sorry, I don't get it. How can you only run selected code or lines individually without the full context of the program/project that code is part of?

This style of doing things is very common in languages with a (good) REPL, think clojure or ipython. You keep sending snippets and iterating on them until they work as intended. For that, you don't need the full context of your program.

Not a LISPer but apparently in that land you could actually have the program running and a REPL attached to it, in which case, you actually do have all the program at your disposal.

The only nice REPL I have experience with is ipython. And even a few years ago, just turning on autoreload allowed me to do that without selecting anything and copying / pasting, just edit the function in the editor and run it again.

IIRC the docs said there were some edge cases, but I never ran into those.

Why do people keep repeating it... Python doesn't have a REPL. It has an interactive shell. Read-eval-print-loop relies on being able to feed what you print back to the read function. Interactive shell doesn't need the ability to print code: it prints whatever information a function wants to print (often times nothing).

In Python sometimes you can feed back the results of a function into some other function (when you are in the interactive shell), but usually they are nothing like Python code...

Here is a super basic example of running rails code: https://cln.sh/xXNlf51m

Now imagine instead of a empty rails shell, I had my server running there and I can set breakpoints. Or why not both a shell and a server?

Stealing this. I'm using send-keys to run specific test examples under my cursor (sends test_command current_file_path:current_line_num)

How is that done?

I'm using this to send what's copied into the clipboard to the other target:

    bind r run 'xsel -bo | tmux load-buffer -; tmux paste-buffer -t .+'

Any chance your configs are on a repo somewhere?! For rails vim and for this tonic setup (if there’s even configs needed for that)

Think of a REPL or shell (which I guess is a REPL…). Same thing you might do in a Jupyter NB.

I'd imagine he's talking about language with REPL

I select it with a mouse and paste it with middle button...

tmux is for people who hate touching the mouse. It almost could stand for “touch mouse? Unthinkable eXercise!”

I started out as a vim+tmux purist and couldn’t agree more. I mainly use vscode now but I still use vim keybindings. I loathe having to use the mouse and I think I will forever.

This. It changed my workflow from "type commands directly in your terminal" to "type commands as a playbook, then execute the playbook line by line". Self-documenting, no copy-pasta errors, a full curated history of your workflow in plain text without having to reconstruct it from shell histories.

I am verry happy with `screen` which I use for ~10 years.

Hear about `tmux` here and there, but so far not sure about the benefits. Any particular reason it's better over `screen` ?

How do you split viewport to see multiple screens at once, how do you iterate over viewports?

Screen does that. They call it "Regions".

https://www.gnu.org/software/screen/manual/screen.html#Regio...

Ctrl+a n and Ctrl+a p will move to the next and previous screens respectively

I switched from screen to tmux after almost 20 years of using screen. The impetus for the switch was that I found a bug in screen, and discovered that it had been reported for many years.

tmux handles changing terminal sizes better than screen does. The config language is much easier to read and write. The status line looks a little nicer.

same here

screen knowledge is still valuable as it is more commonly installed

If you use screen mainly to disconnect a terminal from.m an SSH session then tmux won’t do much for you. However, it would be easy to switch because you’re only scratching the surface.

If you use it heavily, then you may be hitting limitations and it would be worth experimenting with.

I find that I do most of the tmux-like things with multiple iterm windows instead, but I’m a lousy mouser.

iTerm2 actually has a pretty well-designed tmux integration[0].

Overview from the guide:

  When you run "tmux -CC", a new tmux session is created. An iTerm2 window opens and it acts like a normal iTerm2 window. The difference is that when iTerm2 quits or the ssh session is lost, tmux keeps running. You can return to the host you were ssh'ed into and run "tmux -CC attach" and the iTerm2 windows will reopen in the same state they were in before.

It works with multiple panes, windows, etc. Worth trying out!

0: https://iterm2.com/documentation-tmux-integration.html

If you're that happy with `screen` I would suggest that you just continue using it. I also was a `screen` user initially.

Later, I switched to `byobu`, which started out as a wrapper around `screen` by Dustin Kirkland (of Ubuntu). At some point `byobu` switched to wrapping `tmux` to fix some corner cases/bugs, and it now prompts on first run whether or not you want `screen`-like ctrl-a behavior. https://linux.die.net/man/1/byobu-ctrl-a

It’s like comparing Apache to nginx. They’re both very similar.

The biggest complaints with screen is that the source code is a disaster, and it’s slow with lots of windows, and has put mouse support.

Tmux is very configurable, I used screen from 2005 until 2017 when I went all in on Tmux. My muscle memory couldn’t adapt though. So not all my Tmux bindings match screen.

I may be alone on this, but kitty¹ with sessions has nearly eliminated my use of tmux.

[1] https://sw.kovidgoyal.net/kitty/

Any terminal that has rich pane manipulation semantics can serve to take the place of tmux, this includes kitty.

The one thing kitty can't do, however, is have a remote session that keeps your workspace intact. I, and many other devs, purposely disconnect our development from any given machine we're on.

The majority of reboots or other disruptive behavior is because of desktop machines (for those of us that don't use Linux as our primary and only desktop OS); running the tmux session off another machine (even if its just a headless machine under our desk) minimizes disruption due to GPU/etc bullshit.

I think wezterm should be able to do persistent sessions when its mux server is installed on the remote side.

I will find out more info and come back.

I was told this indeed works.

Terminals are often single platform (I don't know a single one that is cross platform).

If you use multiple OSs, tmux offers a consistency that paned terminals cannot offer.

Alacritty, wezterm, kitty.

Alacritty is not paned, kitty does not support Windows.

wezterm seems actually legit, I didn't knew it. Thanks!

I want to add that I've been using tmux for the last decade.

I went from gnome-terminal, konsole, multiple remote ssh sessions (tmux on the remote side for long running sporadic jobs like repairing databases), Windows Terminal, iterm, iterm2, kitty, putty, etc etc etc. From ancient Ubuntu (from CD-ROM giveaway era), to modern MacOS releases, from several Windows releases.

Happy camper of wezterm for the last 6 months. Alacritty as secondary, Windows Terminal on my gaming machine (wsl2 for some stuff).

Between them: still the same tmux config, just evolving, changing plugins, colors of the status pane, adding starship.rs to the mix. Very tempted to try zellij harder, but not sticking to any of these terminal interfaces provided me lots of flexibility and consistency.

xterm exists everywhere X does (even Windows).

xterm does not have panes or any particular tmux features I'm interested in

even locally, when the GUI hangs and i need to restart it (Xwayland still has issues), having most of my work in local tmux sessions saves a lot of time after logging back in.

Discovering tiling window managers (it was i3, I now use sway) stopped me using it - I only really did for tiling I suppose, then discovered I could have that for other apps too.

Same here, but kitty is inferior in some respects. I still don't know how to this [0] in kitty...

[0] https://mbork.pl/2022-01-10_Simple_tmux_scripting_revisited

Just fron reading the docs, https://sw.kovidgoyal.net/kitty/remote-control/ in general and `kitty @ launch` in particular seem relevant.

I had this for a while, I suspect a lot if users are like me (and I assume you) in that the functionality they need from tmux is more or less just tabs and splits (tmux does more than this, but I don't tend to use those features) which kitty replaces pretty nicely.

Since I work across actual Linux and WSL I really appreciate having something that's terminal agnostic like tmux since it means I don't have to have a separate set up when kitty isn't available.

Every time I accidentally close my terminal with full setup running or I'm away from my PC but would like to check on it and do some simple stuff from my phone, I'm thankful for having tmux

I have been using vim and tmux for over 10 years as my primary development setup. I have tried others things like vscode, jetbrains ides and even cloud based ides (like cloud9, before Amazon bought it).

I have always gone back to vim and tmux for everything I do.

I have been using tmux as my primary "IDE" for quite awhile now, largely because I am such a sucker for absurd modularity. Tmux let's me glue together a bunch of arbitrary things while still allowing me to stay entirely on the keyboard. I use nvim right now, but I could change to Emacs without changing the rest of my workflow.

So I already use a tiling wm (sway), and a tui editor (helix), and I have tmux installed but I never get around to diving in and figuring it out because most of this navigation and pane splitting stuff is just duplicating what my WM already does.

Besides being able to SSH into a session, what does tmux really have to offer me, from people who use it?

> Besides being able to SSH into a session

Does it need to do anything other than that? I simply can't imagine not having that feature. The way I use computers would have to fundamentally and radically change.

I have long-running sessions on a personal server which I can access from any computer or mobile device I own, seamlessly. I can start compiling, put away the laptop, go do something, and come back to the complete job later. I can check the progress on my phone.

But, I don't actually bother with tmux on the laptop. You're right that the tiling features are not essential on their own (but do become useful in the context of a remote session).

Well, I do all my development on a single machine, so the SSH thing doesn't appeal to me that much. Maybe when I'm running something in production on a headless server somewhere, but why do development that way? I use other TUI tools that way and they're great.

I was hoping for some other awesome use cases of tmux, because I really want a reason to use it.

This looks nice, but what is the benefit?

The pane thing looks nice until you start to use it. There is typically not enough space on the screen to have all useful information visible and then it's simply distracting.

I prefer to use multiple monitors and have terminals on fullscreen. I understand it's not always viable (space, cost etc.) then I still prefer to switch between fullscreen windows than use panes.

The same with code editor. I tried to split windows e.g. to see code side by side, but even if you have your code limited to 80 columns, you may still not be able to see the whole lines, so in the end it's just more faff.

If you switch full windows you can also train your short term memory, as you need to remember the context more and you can focus more.

But each to their own...

I usually use panes to do things in the same folder or related to the same purpose but which I want/need in different shells. Possible example is visual comparing files or outputs. Also useful when you run some monitoring in another shell - my recent example was debugging build system rules by running cmake+make in one pane and immediately seeing what options are passed to compiler by running execsnoop in another pane. Or you may find useful small panes with something like `watch grep ...` or `watch df -h` etc.

My tmux setup looks like this: one session - bunch of windows for different purposes (for example, developing different projects), no more than 10 so you can switch between them with digit shortcuts, renamed for convenience - each window may have several panes, usually one is maximized but you can "unmaximize" it and look what was printed in other panes before (so one usage of pane is a temporary buffer for output) or run something there.

Same here.

I have always thought it was super sexy to have all these panes available with an editor, logs, debugger opened at the same time ; but the reality is that I cannot work with 20 characters columns.

I use a 4k display set to HiDPI (1080 lines) and simply switch between my full-screen panes.

Sometimes I will split my tmux window vertically because I can deal with fewer lines but I never split horizontally.

> There is typically not enough space on the screen to have all useful information visible and then it's simply distracting.

Most of the time I have two panes open (side-by-side, splitting the screen vertically). This is plenty of space on 23" monitor, and it even feels somewhat empty on 27". Sometimes I hide another plane (C-b z), especially if I need to switch into character mode and copy the contents of the terminal window. Another case when I need to hide other panes is when I need to read logs from journald and some of those have very long lines, and It's just very uncomfortable to have to move the pager left and right.

I also usually have 3-5 windows open. Eg. because I'm logged in as different users (so, I also rename the windows to help remember that).

Ultimately though, two panes is the way to have the editor open in one pane and something that the code written in the editor affects in the other. For example: one pane has Helm charts, another pane has kubectl running with some pre-configured environment and deploying / removing those charts. Or debugging a Python program, where in one pane I have the source and in another I'm running the program and giving instructions to the debugger. So, eg. once the debugger prints the location in the source it's at, you copy it and navigate to that location in another pane to examine the broader context.

> if you have your code limited to 80 columns, you may still not be able to see the whole lines

Are you like on a 13" laptop or something? If that's your working condition, it sucks for you anyways. It's just not a comfortable working environment. You can find a second-hand 23" monitor for a few bucks, sometimes nothing -- people might give it away as long as you collect it from them. And you don't need any super characteristic for programming... so, why not invest a little bit and make your life more comfortable?

How big is your screen? What's your resolution? How far away are you sitting?

I'm on a 4K 27" monitor, and I can easily squeeze two columns of code, each 120 characters long, and still have room for my project structure view. If I limited my code to 80 characters per line, I could fit 3 vertical columns.

Though I love tmux, when vim added terminal support I switched off it. It's not a full replacement; there aren't really sessions and you can't detach, but still vim covered 100% of my uses.

I find that vim does not offer enough nesting for me. There is basically tabs and windows (yes I know vim tabs aren't really tabs). When I need to work on 3 different tasks, each spanning 5-10 git repositories and multiple build environments, I need to have multiple tmux windows and sessions to keep everything in order. Sometimes I even go all the way up to 5 nesting levels: "tabbed"/multiple terminals -> tmux sessions -> tmux windows -> vim tab pages -> tmux panes/vim windows (interchangeable)

My biggest annoyance is that vim doesn't really support multi process setups, but this can be somewhat fixed by opening vim in read-only mode by default (it won't complain about swap files).

Everyone look, this is the horror that microservices hath wrought.

Embedded, actually

Hah serves me right for trying to be clever; apologies. Incredible setup you've managed to set up there.

(Or you could use Emacs…)

I use both. Specifically, in Emacs I use ansi-term, and from there I use tmux.

There are some more configurations that I had to make, specifically for copying and pasting, but I should probably spend more time to code better integration (I would love it if Emacs could put things in tmux clipboard, so that I only use one paste command, similarly, I'd like that in tmux buffers all copying would put things in tmux clipboard instead of Emacs / terminal / tmux).

The reason for me to do it is that I have to work with my allocated resources in our datacenter, and I want to keep my workspace intact between the times I disconnect from it. Also, it's sometimes easier to work with an editor local to the filesystem where I need to edit the file vs using Tramp (esp. if the files are large). So, I typically go for vi in tmux (inside Emacs) when I need to edit something remotely. Even viewing long logs with Tramp isn't a great experience.

Consider vterm instead of ansi-term. It is a fully-fledged terminal emulator. https://github.com/akermu/emacs-libvterm

What am I missing in ansi-term? I never felt like there was something lacking...

The linked github page says: "However, term and ansi-term do not implement all the escapes codes needed, so some programs do not work properly."

Tmux is great for monitoring remote systems. I simply have htop along with some other monitoring tools in a window, and other windows to run commands on my remotes. Combined with autossh, it means I can just be always-connected to my remote devices. Tmux keeps the sessions open on each machine, and autossh reconnects to them from my device when the network is back within reach. That way I just have one tab per remote.

What is autossh? It sounds somewhat like mosh - https://mosh.org/

somewhat different

autossh is basically a wrapper script to keep a session established by reconnecting

anyone using more than one session ? I usually just have one big one and script to create new one within that

    mux () {
 sessions=$(tmux list-sessions) 
 if echo $sessions | grep -q -P '^main:'
 then
  session_id=$$ 
  tmux new-session -t main -s $session_id -d
  if [ "z$1" != "z" ]
  then
   window=$(tmux new-window -d -P -- $@) 
  fi
  tmux attach-session -t $session_id \; set-option destroy-unattached on \; select-window -t "$window"
 else
  tmux new-session -A -s main $@
 fi
    }

+ rofi (I know, heresy, choosing tmux session via X tool) attached to C-b s to search within window list

I use autossh+tmux for persistent ssh sessions. I don't use mosh as I use X forwarding to share the clipboard with the host, and I don't think mosh can do that.

I don't really use tmux for window/pane management, I have a window manager and my terminal emulator has panes and tabs. Each autossh session gets its own tmux session on the remote side.

Yep, I have a very similar script in my home bin that I use for the same purpose. I've been using tmux this way for probably a decade at this point.

Just use a proper IDE already

I use proper IDE for near everything people say tmux makes possible but I still use tmux for various stuff, it's just a very useful tool.

Only one issue I had is that compared to screen default shortcuts are absolutely fucking awful for doing any kind of useful work so I had to remap most of them.

Just use emacs already

No, sorry, I value my time

What if you have to develop on remote machines?

VSCode and JetBrains support this in various configurations.

You can edit the code locally and deploy via ssh. Or you can edit the code via ssh; or you can run the entire IDE remotely via ssh.

I just can't bring myself to spend hours mastering something like tmux, emacs, vim or the like (like learning a million keyboard shortcuts). I personally would rather spend those hours learning pretty much anything else; as in, I can't think of something more boring than learning a new text editor that's convoluted in the name of extreme productivity.

It seems to me that it's not a huge win in productivity; like, it's not like it's something that's going to make me 10x more productive. I spend more time thinking about the problem than writing code, for non-trivial problems. And even when I write code, it seems that using emacs or this tmux setup wouldn't be a huge win. Even if that saved time adds up, a bunch of hours at the end of the year is not going to make a huge difference definitely not something that's going to fundamentally alter my career.

Some productivity guru would say you have the correct mind set.

Chasing the perfect productive setup is a big sophisticated procrastination trap.

But tmux does bring in value. The fact it makes it possible to keep a remote session running even when you lose connectivity is worth learning at least 5% of that tool.

It wont make you even 1.1x more productive. It will in fact make you less productive. But it looks cool so some people insist on using these clearly inferior setups.

More advanced tmux/nvim/emacs/etc. setups are effectively a TUI IDE as opposed to a GUI IDE.

Different people have different preferences.

As someone who moved from jetbrains to sublime-text and then helix, I can safely say I'll never use a graphical IDE again. They're so damn resource heavy, a good text editor and a terminal window do great.

Why does a graphical IDE being resource heavy matter to you?

Because it's running on my machine, using my resources.

You’re talking about it as if it’s costing you money

Do you take the same stance when your browser does the same? Have you disabled JS and embraced the digital amish lifestyle?

It does cost money. It costs in electricity, and in cost for hardware.

Yes, I do turn off JS in my browser.

I think a major problem in software development right now is the mindset you have. I want software that just does what it needs to and has as small of a footprint as it can to do that. I avoid topheavy software.

I hate graphical IDES because of how slow they are

* look through menu items * click something * everything is frozen for 5 seconds, fan start whirring.

Yeah I know. Junk my computer, get a new one, I'll pass.

Reply on news.ycombinator.com