Juggling multiple read-only "compiler output" "watch" terminals

I'm running into this weird monitor-real-estate problem and am wondering if others have run into it / have ideas on how to deal with it.

  1. I'm writing my code in IntelliJ / Rust plugin, which takes up one monitor already.

  2. I also need to monitor the following terminals:

cargo watch // server side Rust code
cargo watch // client side Rust code, compiling to wasm32
console for Rust server // http server in Rust, dumps out GET / POST / ... requests
tsc -w // project is 90% Rust, 10% TS
esbuild terminal // for combining rust's wasm/js output and ts codebase

so here we have 5 terminals; they're all 'watchers' in that I don't send them any input, but they send me output

the problem I'm running into is that I'm running out of screen real estate; I have these 5 terminals squished up in a 2x3 grid, at most of the time, 4-5 of them are constant / not changing, and I only care about 1-2 of them (which contains debug errors)

The XY problem here is that due to the 2-3 grid, all the terminals are tiny / short, making it annoying to see their content / debug errors, yet at the same time, I only care about the output of at most 1-2 terminals.

I'm wondering if there is some smart tool that either (1) intelligently interleaves the output of all 6 terminals or (2) intelligently resizes the terminals [by who's pumping out new errors] or (3) something else for dealing with too many "watch terminals"

1 Like

I use i3 (a tiling window manager) for my daily driver and usually have VS Code open on one screen, and my terminals open on another.

The cool thing about i3 is that as well as tiling your windows (e.g. like how you have a 6x3 grid), you can also organise windows into tabs and stacks, so in theory you could have one tab showing your frontend-related windows and another tab could have backend-related windows.

Or to answer your specific question, if your OS has the concept of workspaces, you could have your IntelliJ workspace on one monitor, and the second monitor could switch between multiple workpaces, where you've grouped windows which are related (e.g. cargo watch client, tsc -w, and esbuild terminal) on the same workspace so you are only ever looking at a subset of all your terminals at any one time. That'd free up screen space to allow each individual window to be larger.

2 Likes

My setup is almost spartan: I use a KDE desktop with generally only 3 apps open: Firefox, Emacs, and Konsole. The nice thing about Konsole is that it supports tabs, and that's how I scale up my terminal usage.

Now granted you can't see them all at the same time, but generally I don't need to, so it works out nicely.

I put my watches in a tmux session, arranged as a grid of tiny panes. I can then use C-b C-z to "zoom" a single pane, and have it fill the entire terminal.

That way, I can see at-a-glance if any pane contains interesting output - if it does, I zoom in on that pane, and it fills my entire terminal. I can also maximise the terminal so that I get even more real estate when I've seen something happen.

3 Likes

There's this tool called multitail that can do this. It's like tail but it can also read from processes. You'd call it like this:

multitail -l 'echo 1; sleep 4; echo 2' -l 'sleep 2; echo a; sleep 2; echo b'

And it will split you terminal window into multiple "views". See MultiTail for screenshots and here for examples.

3 Likes

This is really cool. For anyone else setting this up, the commands I'm using are:

u: select window
U: show all window
-cT -ansi -l "... command ..." : runs command, interpreting ascii color codes