Maximize screen real estate

Real estate is expensive. Bad room layout can make a large flat seem small and a small flat seem large. A space with too much furniture can seem small even if it is large and a place with just a few select pieces of furniture can seem large even if it is small. All of this also applies to screen real estate. Especially with smaller laptops with lower resolution displays, it is nice to get as much space as possible for the actual content and waste as little as possible on distracting UI elements that makes the screen seems smaller than it is. By having more space for the actual content, you also minimize scrolling.

I achieve max pixel efficiency by using the tiling Window Manager Sway. Since it is a tiler, it automatically places windows in a tiled layout. Compared to working in a floating WM or Desktop Environment, I save a lot of mousing around to move my windows. I have a nice wallpaper, but no icons that clutter up my desktop. I have set up Sway to have 2 pixels of border around each window and no title bar on top to get as much space as possible for the programs I work in. The two pixels are needed to see where one window ends and another starts and also to distinguish between the active window with a red border and the inactive window(s) with a blue border. One pixel was hard to see, so I went for the somewhat wasteful setting of two pixels in stead.

I have also set smart_borders on which means that if I have only one window on a virtual desktop, it is without any border at all. This saves four pixels in both directions and looks nicer. I use a small 12 inch Thinkpad X230 with an internal 1366 x 768 pixel display as my main machine and usually just one program per virtual desktop, so the smart_borders make a difference. On my external 2560 x 1440 pixel 25 inch wall mounted screen behind my standing desk, I am more inclined to have two programs side by side if I am actively working on something in one window and just need to look something up or do a related task in another window. Humans are generally worse at multitasking than we think, so I like to separate different tasks on different virtual desktops even on large screens to not get distracted.

I do not use a panel on the top or bottom of my screen since this wastes pixels in the directions most screens have the fewest (height). I have set up the built-in Swaybar to autohide. I use scripts launched with keyboard shortcuts for the few things I need that most people keep in their bar or panel, like getting battery status in a notification or turning wifi or bluetooth on or off. A benefit of using scripts launched by the keyboard in stead of a bar with lots of information or system tray applets is that I save mousing around in submenus of my system tray or clicking on my panel to get things done. Since Sway implements the system tray of Swaybar in an xdg standards compliant way, but most programs still use a legacy Gnome implementation, most tray applets do not work anyway and this is what forced me to think closer at what functionality from the system tray I actually needed in the first place.

Over time, I have gradually switched out some of the larger GUI programs I used with smaller, simpler, more customizable and easily scriptable tools. Some of them are terminal programs, some are Emacs packages and some are small GUI programs. Many of the small GUI programs also have a minimal GUI that only present a few very useful elements and is otherwise controlled through keyboard shortcuts, like zathura or mpv. By having very few user interface elements, these programs give more room to the actual content you read or watch. The same applies to the TUI programs and Emacs packages I use.

Since switching from vim to Emacs, I have integrated some of the tasks I used to do in separate programs into it. Emacs is very efficient since it is so keyboard and text centric and by having fewer programs, I save the cycles my brain would use for context switching with different keyboard shortcuts for different programs. Emacs also has the ability to run both in a GUI which is what I normally use (since it adds support for different fonts in different contexts, pictures and PDFs), but can also be used in a terminal emulator or the tty with most of the same functionality. An example of how I gradually have integrated my workflows into Emacs is that I recently stopped using PCManFM as my file manager and instead now use Emacs' dired and the GNU coreutils in a terminal (inside or outside Emacs).

To save space in Emacs, I turn the menubar, toolbar and scrollbar off which saves some pixels on the top and right side of every window. I instead use F10 for the occasional dive into the menu and keyboard shortcuts like C-v and M-v to scroll down or up and M-< and M-> to go the the start or end of a document. I also turn on showing column and line numbers in the modeline and do not turn on line numbers on the start of every line since I can easily find the right line with the modeline if I am debugging something with an error on a specific line. It looks a bit cleaner and saves some space on the left of the screen. Usually, this does not matter much since screens are generally wider than they are tall, but when having three windows with code side by side on a small laptop screen, it can be the difference between having to scroll horizontally or not.

All in all, by saving some pixels here and there, I get more space for the content I work with, watch or read while also reaping the efficiency benefits of a more text and keyboard-centric workflow that came as a consequence of having fewer visual clues on screen and using the mouse less. A lot of functionality is not obvious at first sight, but since I have set this up myself and know my keybindings and the available functionality, it works well for me. Sometimes less really is more.