Hacker News Reader

Comment by eridius | Hacker News Reader

I've never worked in a situation where I could use a tiling window manager (OS X here), but I've always wondered how that's supposed to work when my normal workflow involves opening and closing a lot of windows. Especially terminal windows. I open throwaway terminal windows all the time, and then close them if I'm done with them, or keep them open behind my other windows if they have some information in them I need to reference later.

Often when I'm done working, I end up closing perhaps a dozen scratch terminal windows.

View on HN

Tiling window manager users typically avoid transient windows in much the same way that modern browser users avoid transient browser windows.

For instance, my primary development workspace has four columns: three emacs and one terminal with tab support. I don't open/close new emacs windows or new terminal windows, in the same way that I don't open/close new browser windows: I just use tabs within a single window. Likewise, I use multiple open buffers within my emacs windows, and multiple tabs within my terminal windows. If I need a transient terminal, I switch to a different tab or add a new tab.

Opening/closing transient terminals is pure UX overhead, IMO.

I use transient browser windows all the time. I try and group related things into tabs, but a page I just want open for a second usually gets a new window. It's easier than navigating the flat tab list.

Terminal multiplexers like screen and tmux are a nice alternative to tabbed terminals. They cut down on screen clutter (no need for tabs, scrollbars, etc.) and have the added bonus that they remain running in the background, even accessible over SSH.

(I accidentally killed my X session this morning; everything in tmux survived :) )

Optimal Layout[1] works pretty well as a tiling window manager (or close enough) for OS X. I've been using it as an essential part of my workflow for 2+ years. I also make heavy use of emacsclient and tmux[2] sessions and windows in conjunction with iTerm2[3].

When I have some time to experiment, I'd like to look at replacing Optimal Layout with mjolnir[4] or one of the similar tools listed in mjolnir's README, under Mjolnir vs. other apps.[5] Amethyst[6] looks like another option worthy of consideration.

[1] http://most-advantageous.com/optimal-layout/

[2] http://robots.thoughtbot.com/a-tmux-crash-course

[3] http://iterm2.com/

[4] https://github.com/sdegutis/mjolnir

[5] https://github.com/sdegutis/mjolnir#mjolnir-vs-other-apps

[6] https://github.com/ianyh/Amethyst

Optimal Layout looks interesting. I'll have to give it a shot.

Another one you might want to look at is Witch[1]. I've tried it before but it never really "stuck" for me. Maybe I should give it another shot. Witch isn't a window manager though, it's only concerned with making it easy to switch between windows rather than laying them out.

Why do you use iTerm2? I've looked at it in the past, but it just feels non-native enough to bug me. I know they advertise tmux integration, but the one time I tried to find out what that actually entailed, it didn't seem to work for me (though I've been told it basically just uses iTerm2 native splits in place of tmux splits).

[1] http://manytricks.com/witch/

I started using iTerm2 some years ago. I tried the built-in Terminal.app again earlier this year, just to see if it would work for me, and couldn't figure out how to easily "fix" the keyboard input so that terminal-mode Emacs works as expected, with respect to key sequences involving meta. iTerm2's preferences panel makes the same "fix" quite simple, so I'll be sticking with it for the time being.

Terminal.app doesn't quite have the right default set of bindings, but iTerm2 also has some wrong bindings around the meta key.

If you want to enable option-as-meta in Terminal.app, you select the Profile you want in preferences, go to the Keyboard tab, and there's a checkbox at the bottom. This is also where you can customize the bindings for various key sequences, if you think they're wrong.

I checked out Optimal Layout. It seems possibly useful at first glance, but I already had to disable it, because there's no way to turn off the keyboard shortcuts while in specific apps, and I need to have the keyboard shortcuts disabled while in World of Warcraft.

There are plenty of apps that provide varying levels of window-manager functionality to OS X. I would try a couple out and see if any seem useful to you.

http://manytricks.com/moom/ http://mizage.com/divvy/ http://ianyh.com/amethyst/ http://spectacleapp.com/ https://github.com/fjolnir/xnomad https://itunes.apple.com/us/app/bettersnaptool/id417375580?m... https://github.com/sdegutis/mjolnir

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.

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.

Reply on news.ycombinator.com