Hacker News new | ask | show | jobs
by photex 4208 days ago
Using two monitors on Linux and running XMonad changed the game for me. Very organized, productive and efficient interactions with the system grew organically out of it. Even though I tend to use KDE (and KWin) these days on a laptop, that experience helped me drill down into a workflow that I apply anywhere I can. The best thing is that, everybody comes to their own "most efficient" workflow using these tools. Interacting with OSX/Quartz after that felt something akin to giving up <insert code editor or IDE of choice here> and writing all your code in [TextEdit.app | Notepad.exe | nano].

Also, scratch terminal windows are solved by TMUX and a single terminal.

wtftw is very interesting. I can't wait to give it a shot.

1 comments

Terminal.app supports tabs, I'm not sure why tmux would be any better (well, tmux can do splits, but transient windows don't need splits).

The problem is if I create a tab, I want it to be at least somewhat related to the other tabs in the window. And even then, I usually use new windows for scratch terminals because I want to see multiple different terminals side-by-side. I could use a vertical tmux split except that shrinks the original terminal, and I want both the original and new terminal to be at their natural size.

TMUX is a transferable implementation of terminal session and "tab" organization. It's also scriptable if you aren't happy with some aspect of it's default presentation or interaction. For me, that is enormously valuable.

Sounds like your use case could be mapped by TMUX windows acting like Terminal tabs, and TMUX sessions acting like multiple Terminal windows. Except the benefit is that now you can use this workflow on any system with a posix compliant shell and a tmux binary (which I'm pretty certain is practically all the things at this point). Sessions and windows can be given labels which is a nice touch too.

If you are an Emacs user, it's also worth noting that TMUX totally works well with ansi-term. :) I normally have a TMUX session dedicated to an ansi-term buffer in Emacs. Even if I have iTerm or Konsole using another session.

"..but transient windows don't need splits"; well, in my universe transient windows are splits. :)

Anyway, I don't want you to think I'm trying to persuade you into adopting what I consider awesome and useful. Just clarifying my statement. It sounds like you already have a workflow, are happy with it, and don't see any need for alteration.

I use tmux over mosh on my Linode. I've just never found it to be particularly useful on my local machine. Especially because it removes the ability for my terminal to manage history and requires using a keyboard shortcut in order to scroll backwards in history.
I believe Terminal.app handles mouse events differently, so the standard tmux config doesn't work right. Maybe see if https://bitheap.org/mouseterm/ improves matters for you.
Terminal.app doesn't handle mouse events at all. I filed a radar for that a while ago. But I don't consider that good enough reason to use iTerm2 as the programs that actually support CLI mouse events are very rare.