I do most of my coding on the command line, so: some views on terminals.
I like having lots of terminals side-by-side, to see many different things simultaneously. Most places I’ve worked have kept code to 80 columns, with two-space indentation, which is a good fit for my approach. Here’s how I usually have my terminals set up:
The monitor is 27″, at 2560x1440 (“QHD”). This has room for five 83x101 terminals, though I usually divide my rightmost terminal vertically for long-running commands or interactive prompts.
On traditional resolution (non-retina) displays, I have a strong preference for bitmap fonts without antialiasing. They are much clearer at a given size, which allows fitting much more text on a screen. In iterm2 this means selecting Monaco Regular at 10pt, and leaving the “antialiased” box unchecked, under Profiles > Text.
At some point I could see moving to a higher resolution display, but probably not until 5K monitors (my current resolution, but 4x the pixels) are widely available and reasonably cheap. High resolution displays are a bit nicer, but I don’t mind the regular kind.
Aside from moving from Linux to Mac, and getting wider monitors, this is a setup I’ve had for a long time.
Comment via: facebook
I only ever have one terminal open. I do everything from it. All of my terminals have their .zshrc configured to spawn or connect to a single, global tmux instance, and I use tmux’s multiplexing to manage all the terminals I need. It allows me to organize, label, split, and quickly navigate between window panes, and keep things much more sane when I start using up to 9+ windows at a time.
IMO, it’s absurdly better than having a bunch of different vterms. Tmux’s conveniences make it possible for me to use the terminal in ways I would not be able to otherwise. Configure tmux to spawn new panes in the same directory as the one you’re creating them from for extra damage.
In addition and so I can spice this comment up with a bit of extra controversy, I also have .zshrc open up the “lf” TUI file manager for every new tmux pane; this helps with quickly navigating to the place in my filesystem I want to be without running a bunch of damn ls and cd commands.
When I tried using tmux to get a similar effect the main problem I had was that if I tried to select text with the mouse it didn’t understand my panes. And I couldn’t figure out how to get it to do focus-follows-mouse between the panes.
If I could get proper mouse integration working, however, I do think I would like a “one tmux for everything” a lot better.
(I do use tmux, though, just only for it’s session resumption ability: https://www.jefftk.com/p/persistent-sessions)
The enlightened tmux perspective is that you should always be using the keyboard to navigate between panes because it’s better and there’s no reason to use your mouse anymore, and that selecting text just sucks but you can always C-b+! to break a pane into a new window and then select it as normal.
I try to minimize how much I type, because of wrist/hand issues, and I want to move my hands in as many different ways as possible. Using the track pad with my thumbs or fingers to move between windows works very well for me, and isn’t something I’m looking to move away from.
I wonder if it’d be worth trying a trackpad or figuring out how to assign mouse gestures to keystroke macros. I’m exactly the opposite—I try to minimize moving my hands off the keyboard, except for designated stretches, but I’d think the same underlying approach is valid—figure out movements that feel natural and easy, and make them do precisely what you want.
Tmux only has the default prefix be C-b because it was developed inside Screen, which has C-a. But the first thing that everybody does is to map it to C-a.
I like C-b, because C-a means “go to beginning of the current line” and I wasn’t using C-b for anything.
In screen I used to use C-^
lc’s response is kinder than mine. I was about to respond “that’s because focus-follows-mouse is pure evil and anti-productive (which is a direct result of the fact that mice are useful for graphics and browser-like-navigation, and the keyboard should control everything beyond that)”.
[ edit: I apologize for the tone of the previous paragraph. I intended it as jokey-flamewar-style, but I later re-read it and found that I just sound like a jerk. Sorry. ]
I do agree that for the special case of text selection that requires scrolling (because it’s larger than the pane), tmux gets in the way. This is a rare enough thing for me that it’s well worth it to do everything in a tmux session. YMMV, obviously.
Note: I do recommend to anyone who spends more than a few hours per day doing this kind of work, in addition to getting good monitors, investing in a very good keyboard. I’ve grown to love https://ultimatehackingkeyboard.com/ - the split keeps my wrists straight, which minimizes my RSI issues, the right-thumb trackpoint and lack of 10-key means I don’t have to move far when forced to use the mouse, and the programmable layers mean I stay near the home row most of the time, and use VI movement for navigation (arrow, home/end, pgup/pgdn all use VI bindings on the mod layer). I still use a timer to stand and stretch every hour, but this makes it much more comfortable and efficient for long periods of use.
Different interfaces are right for different people? Sticking to the keyboard for navigation may be a good fit for your hands, but it’s definitely not for mine?
This works in Ubuntu 20.04:
From the place I got it:
More generally, here is my .tmux.conf, in which copying with the mouse works, as does copying and pasting.
Before I dig into this, does this also include focus following the mouse between panes?
Only if you click
Thanks! I was confused because you also quoted my “I couldn’t figure out how to get it to do focus-follows-mouse between the panes” bit
I started with screen for multiplexing and session persistence. Later I switched to tmux. I liked it fine, but Emacs has been gradually devouring my workflow for a long time, so before long I dropped tmux in favor of splitting windows and running shells all within Emacs, and using its server mode/emacsclient for session persistence (with a little help from dtach to keep emacsclient itself running to remember my window layout). Just recently I’ve dropped dtach as well in favor of a few lines of elisp to save and restore alternate window layouts.
For anyone on Windows, the newish Windows Terminal is really nice. Give it a try.
Windows has become a really nice development platform over the past several years.
Yeah for anyone who haven’t seen it, it’s not a minor revision, it’s a completely new piece of software and insanely customizable. Combined with NVIDIA GPU CUDA Support in Windows Subsystem for Linux 2 and you will hardly notice you’re still in Windows. Note that Windows 10 WSL isn’t feature complete with Windows 11.
Tangentially related, what do you use these terminals for? In my experience, I only need about two: one for running the software I’m developing/reading logs and one for miscellaneous software calls like git. Admittedly I do a lot of my current job using an IDE (IntelliJ with Java/Python), so I could see another one or two for text editing and file management.
Not Jeff, but I usually have:
at least a couple of terminals with SSH sessions.
one or two running language tools (like a
blackdserver for python)Since everything using web tech requires building nowadays a terminal building whatever project
A terminal open in my current project directory to run project-specific commands.
Then I usually have a terminal or two open in my Jetbrains IDE....running the software I’m working on.
It is common for functionality to be spread over several different files; most commonly I will have multiple terminals with different files. Perhaps one for the code, one for the tests, and one for the place the code is invoked? Then another terminal for running the tests and seeing the output?
Ah that makes sense. In my usage of terminal text editors I had left my text editor handle loading the different files and splitting the window, but I can see why you would want to just load them with separate terminals.
I’ve worked in dozens of codebases recently (last few years, say), the majority of which did NOT keep code to 80 columns. I’ve seen 100, 110, 100-recommended-and-120-enforced, and “no limit, but you’ll be laughed at if you go crazy”. I haven’t seen a glass tty for 30 years (and even then it had a 132-column mode, but it was ugly). I fine 80-column windows to be constraining pretty often—I consider 120 to be minimum width for my daily use.
I agree with you that vertical space is worth a lot, but esthetically I get distracted by such narrow rectangles. My default terminal size is 124x53, and I spend a lot of time in an IDE that shows 130 columns with a soft-margin at 110.
I’ve grown accustomed to my 34“ 3440x1440 ultrawide—gives me LOTS of room for multiple windows. I’ve also been happy with two 28” monitors—one “main” for the windows I’m working in and a portrait-orientation one to the side for reference and email and such.
Don’t forget the power of tabs and tmux switching rather than having multiple simultaneous windows (also the tmux reconnect-ability). Rarely do I need more than 2 fully-visible terminal windows at the same time.