Setups such as in the article aren't the result of "nerd times" and spending hours configuring just for fashion. They grow slowly over the years out of necessity and annoyance with your current setup.

> it's an OS, a GUI, it's the basis for getting real work done.

The basis for "getting real work done" is workflow. There is no need to be 100% efficient to be productive, but some people, like probably the writer of the article, like to push it to the upper limits, because they might be extra sensitive to "mouse lag" or some other reason.

There is also the extra perk of consistency. Due to their nature, xfce, GNOME, KDE change and consequently break things. Setups like in the article hardly ever change, even after major upgrades.

P.S. Also, as the writer mentions, Thinkpad x200: one of the finest GNU laptops ever. Real keyboard, all Fn keys work. It at a point where if software is too heavy to run on it, it's simply not worth running at this time. Any potential software advantages do not outweigh the superior compatibility and haptic of the hardware.

But when I started working, I switched to Debian, maintaining a Gentoo was a bit costly, and when I wanted to try out something, compiling everything was really slow (you frequently have to wait a few hours).

I still use a minimal setup (dwm with some customization and helper scripts: https://github.com/kakwa/dwm-desktop), and frankly, once it's done, you barely have to touch it, I've not touched my setup in years.

However, I did the same thing as you did and I still use a tiling WM and CLI programs without touching (95% same) configs in the last 5+ years. I am (anecdata I know) faster than anyone who has worked with me and uses a touchpad while editing. All that while being hardware/location independent because I can always replicate my setup easily.

As a related side-note, using a tool properly is a huge productivity booster. I've seen people go from editor1->editor2->editor3 spending significant time learning each tool and still repeating that writing a few config files is a "waste of time".

It's something that doesn't seem useful until you've done it for a while, and then it's hard to go back.

Further i3 has keybinding modes which are sets of keybindings that are activated together. These work like user definable vim modes. A given binding can do one or more operations, and optionally exit the mode.

A brief example.

Everything not in a mode is in the default mode.

A command mode wherein every key is either an action or a mode entered by tapping and releasing left shift.

A workspace switch mode entered by w in command wherein a key is bound to switch to switching to that letter ws. eg left-shift -> w -> a switch to workspace a

An open mode wherein keys are bound to individual applications eg t for terminal b for browser. left-shift -> o t open terminal

Another mode to move a given window to given letter workspace. Another to do the same and switch to it. Another to focus the same app defined in the open mode. Another to get the app from the letter ws.

A mode to control audio including hotkeys for navigating tracks, changing volume, switching all playing streams to different devices, toggling playback.

A mode to kill either the focused app, all in the current workspace or all in the screen. left-shift -> q -> q for current focused, q w for the workspace q e for all visible windows.

You can tab or stack(vertical tab) any app.

You can assign particular workspaces to monitors and particular apps to particular workspaces.

You can a built in tool to run commands based on window rules.

You can save and restore entire windows layouts.

This alone keeps me using i3.

I tried Gnome recently, and although it's very polished, I switched back to i3 because it wasn't nearly as intuitive to drive with the keyboard.

Instead, something I really wanted was to be able to toggle the hiding and showing of all floating windows per workspace. It sometimes happens that I just want to work with floating windows for a while, and the number of windows explodes, and I end up with all these floating windows on top of my tiled windows. Using i3 with the default configuration, I had to manually move all floating windows out of the way to get to the tiling windows below, and then move them back when I wanted to work with them again. That was cumbersome, so I did this:

bindsym $mod+Tab exec "current_workspace=\\"$(i3-msg -t get_tree | jq -r 'recurse(.nodes[]) | select(.type == \\"workspace\\" and ([recurse((.nodes, .floating_nodes)[])] | any(.focused))) | .name')\\"; floating_workspace=\\"F${current_workspace%:*}\\"; if i3-msg -t get_tree | jq -e \\"recurse(.nodes[]) | select(.type == \\\\"workspace\\\\" and .name == \\\\"$current_workspace\\\\") | .floating_nodes | length > 0\\"; then i3 \\"[workspace=$current_workspace floating] move to workspace $floating_workspace\\"; else i3 \\"[workspace=$floating_workspace floating] move to workspace $current_workspace\\"; fi"

Now, I just press Super+Tab and all floating windows on workspace e.g. 6:some-topic get moved to new workspace F6, and when I press it again they're moved back to 6:some-topic, right where they were. This is workspace independent; the windows belong to a workspace. I can hide the floating windows of however many workspace I want and call them back and they won't get mixed.

I think it's pretty cool that i3's configuration and tooling allow for this kind of advanced configuration. It's like I added a whole new feature.

You need to create a keybinding that calls `scratchpad show` using a window class qualifier to target the app you want. That's the key to making the scratchpad useful.

Problem solved! Here is your quake terminal toggle.

1) You can control it from the shell (and hence scripts and hotkeys). For example, `i3 "move to workspace prev"` moves the window to the previous workspace.

2) You can obtain a lot of information of the window manager state (all windows, their sizes, their tree structure, the marks, etc) from i3-msg in JSON format.

1 and 2 mean that the WM is very highly programmable via the programming language of your choice.

3) Workspaces are not fixed. Empty workspaces don't exist unless you're currently in them. You can move a window to a workspace of any name and it will get created. Empty a workspace and when you move away from it, it will be destroyed. This makes it very convenient to work with temporary workspaces.

4) Windows are arranged in a tree structure. Normal windows are leaves. Containers are the branches that take you to those leaves. Containers can be in 4 modes: vertical, horizontal, stacked, or tabbed. That last one means you can tab any set of windows. Why do so many applications implement tabbing when it should be the window manager's job? Stacked is very cool in that it's like tabbing, but the window title doesn't shrink with each added window you have in them. Anyway, this point means that you get a lot of flexibility in how you organize your windows.

5) The configuration gives you a lot of control. These are many small things, so I won't list them all, but as an example, I can put a colored prefix on window and container titles to remind me what they're about without having to focus on them and see their content. I can also match new windows by some criteria and have them appear in a container I tagged without them gaining focus. This is very useful for when I'm doing something in the shell that will cause a window (or multiple) to repeatedly appear but I don't want to lose focus from the shell and I don't want the new window(s) to appear on top of it. As an example of this, I may be running selenium tests which could cause a browser window to appear to show how the tests run. I may also be doing some ad-hoc statistics in octave (cli) and have graph windows appear.

I would say flip the question around: if I can automatically tile windows, why would I use gnome where I have to do it manually?

Let's say I start my server in my IDE and I use my browser to interact with it. Then the bottom right of the IDE (where the console output of the server is) will be visible even with the browser in focus, and so I can see what the log output is doing.

I have got keyboard shortcuts that move windows to predefined positions with predefined sizes. E.g. full height but only the right 85% of the screen. Or full width but only 90% of the height.

If don't already know about `set -o vi` in `bash`, prepare to be delighted.

After all nobody argues that buying a fishing pole and driving out to the lake is the fastest way to get dinner.