Greetings people from the Interweb!
PaperWM is a Gnome extension that implements an experimental tiling window manager with a twist: horizontal scrolling instead of nested grids.
I should start by admitting I've bounced off every tiling WM I've tried. The rationale is sound — floating windows demand constant micromanagement of positions and dimensions — but traditional tiling WMs replace that tedium with a steep learning curve. Memorizing dozens of keyboard combinations to replicate what I could do (however inefficiently) with a mouse never felt like a win.
Gnome conservatively introduced half-screen tiling and it's not bad, but they stopped at that, quarter-screen tiling seems unlikely — I suppose 4 keybindings are unacceptable.
For the uninitiated: tiling WMs automatically partition screen space when applications open — no manual resizing. Traditional implementations (i3, dwm, xmonad) use complex grid layouts with master/stack arrangements, demanding memorization of dozens of keybindings for splits, resizes, moves, and container navigation.
PaperWM breaks from this tradition with a simple metaphor: windows are sheets of paper arranged horizontally on an infinite scroll. Instead of forcing windows into rigid grids, each window maintains sensible dimensions while you scroll left/right with three-finger touchpad swipes or keyboard shortcuts (Super+, and Super+.).
This horizontal paradigm clicked immediately. No mental model of master areas, no stack manipulation, no nested containers. Windows line up left to right, scroll to see them. It matches how I already think about task switching.
After years of bouncing off i3, dwm, and xmonad within hours, PaperWM is the first tiling WM I've continued using. The difference is cognitive overhead.
Traditional tiling WMs demand constant tree-structure thinking. Split horizontal? Vertical? Which container am I in? PaperWM: window goes to the right. Done. On a 13" notebook screen with limited real estate, this simplicity is liberating. Open terminal, swipe right, open editor, swipe right, open browser—linear workflow matches linear window arrangement.
It integrates naturally with Gnome's workspace paradigm. Each workspace gets its own horizontal strip. New windows consistently appear to the right of the focused one — predictable behavior that eliminates guesswork. Moving windows with the mouse/touchpad still works without fighting the tiling system.
Touchpad gestures are the killer feature. Three-finger swipes to scroll between windows feel natural on laptop trackpads. Try the same on a desktop mouse—awkward at best, impossible at worst. PaperWM is clearly designed for notebooks where touchpads are first-class input devices.
Small 13-15" screens amplify this advantage. Traditional tiling WMs force awkward compromises—waste space with padding, or make terminals 40 columns wide. PaperWM shows 1-2 windows at readable sizes, scroll for the rest.
PaperWM requires Gnome 3.28+, locking you into the Gnome ecosystem. No standalone i3-style config, no mixing with other desktop environments. Installation is straightforward from the Gnome extensions website — but it means you're committed to Gnome.
Also Touchpad dependency is real. On desktops with only a mouse, you lose the gesture fluidity that makes PaperWM shine on notebooks. Keyboard shortcuts still work, but the experience is less compelling.
If you've tried tiling WMs before and found them cognitively exhausting, PaperWM is worth 30 minutes if you're already using Gnome. The horizontal metaphor either clicks immediately or it doesn't. For notebook users tired of window juggling but allergic to traditional tiling complexity, this might be the sweet spot.
Howdie Interweb surfer!
I recently discovered you can change folder icons in Gnome programmatically using gio. I was organizing my home directory and wanted to color-code folders visually - doing this through the GUI works for one folder, but 10 folders? Time to script it.
To set a custom icon for a folder or file:
gio set -t string '/path/to/folder' 'metadata::custom-icon' 'file:///path/to/icon.svg'
Note the file:// URI prefix is required. Icons are typically in SVG format. Icons can be found in:
~/.local/share/icons/ (user-installed themes)/usr/share/icons/ (system themes)/usr/share/pixmaps/ (legacy location)Example with an existing system icon:
gio set -t string ~/projects/blog 'metadata::custom-icon' \
'file:///usr/share/icons/gnome/scalable/places/folder-documents.svg'
To see what icon is currently set:
gio get '/path/to/folder' 'metadata::custom-icon'
To revert to the default icon:
gio set -t unset '/path/to/folder' 'metadata::custom-icon'
Remove custom icons from multiple folders:
for dir in ~/projects/*; do
gio set -t unset "$dir" 'metadata::custom-icon'
done
Here's how I solved my 10-folder problem. Simple approach - apply the same icon to all folders:
for dir in ~/projects/*; do
gio set -t string "$dir" 'metadata::custom-icon' \
'file:///usr/share/icons/gnome/scalable/places/folder-visiting.svg'
done
For more control, color-code different project types. My icon theme has 14 color folder variants:
Use a variable to avoid repetition. Replace your-theme with your icon theme name - check ls ~/.local/share/icons/ or ls /usr/share/icons/ to find installed themes:
ICON_BASE="file:///usr/share/icons/your-theme/scalable/places"
# Active projects = green
for dir in ~/projects/active-*; do
gio set -t string "$dir" 'metadata::custom-icon' "$ICON_BASE/folder-green.svg"
done
# Archived projects = grey
for dir in ~/projects/archived-*; do
gio set -t string "$dir" 'metadata::custom-icon' "$ICON_BASE/folder-grey.svg"
done
# Important projects = red
for dir in ~/projects/urgent-*; do
gio set -t string "$dir" 'metadata::custom-icon' "$ICON_BASE/folder-red.svg"
done
If the icon doesn't update:
- Refresh the file manager (F5 in nautilus)
- Verify the icon file exists and path uses file:// prefix
- Check file permissions on the target folder
- Works on Gnome 3.x+ with nautilus/files
- Note: Icon metadata may not persist on network mounts, NTFS, or FAT filesystems - only tried on ext4
Color-coding 10 folders takes under 10 seconds. Much better than clicking through the GUI.
Welcome Internet neighbor.
The Emacs community commonly suggests mapping the left Control key to Caps Lock to avoid RSI. I suppose we can all agree that on a standard keyboard, the real estate value of the Caps Lock key is higher than the function it covers — if we ignore the minority that prefers to type "all caps". However, the popular Ctrl-on-Caps solution will cause long-term harm1.
One of the first things that is taught in a touch typing class is to use a modifier key with one hand and the key with the other. For example, the exclamation point ! should be typed by pressing the Shift key with the right hand and the 1 key with the left.
Having a left Ctrl key right beside the A key is more comfortable than reaching the bottom left corner of the keyboard. This works well when chording2 with keys covered by the right hand. The problem is the implicit suggestion that the left Ctrl in its new position should also be used for the keys covered by the left hand, stretching the pinky and index finger to reach the furthest keys. That movement will create hand problems in the long term. In my experience, lateral finger movements are the most stressful when typing.
My advice would be to extend what's suggested: put the left Ctrl in place of the Caps Lock, but also put the right Ctrl in place of the Enter key. Let's forget for a moment that now we lack a key to enter commands3. To use Emacs with reasonable comfort, one should use a symmetrical keyboard, with pairs of modifiers of generous dimensions in sane locations. That disqualifies the majority of off-the-shelf computer keyboards. What remains is not a big selection — anyone is free to pick their poison: Kinesis Advantage, TECK, Maltron, Ergodox and a few other less known custom keyboards.
And no, before someone suggests Vi mode: I'm not interested in that debate.
The inquisitive reader would point out that notebooks with similar keyboards don't exist. My answer would be to pair it with a symmetrical keyboard again. In my opinion, the comfort of modern notebook keyboards is appalling, with their short key travel resulting from the race to create the slimmest device. By the way, to my horror I've seen desktop low-profile chiclet keyboards too.
Anyway, I know that traveling with a keyboard, even if compact, kills the usefulness of a notebook. For those situations, I've found a better approach:
On my notebook I remapped the Spacebar as a dual role key: when pressed and released it will insert a space, but when pressed with another key it will act as a Ctrl modifier. This works with the touch typing principle because thumbs are neutral and can chord with either hand. It's not perfect as I lose the space repetitions, but who is still indenting code manually in this day and age? For browsing, I can use the Page Down key (unfortunately hard to reach on my notebook)4.
It's a combination of xcape and xmodmap, this is the code I've copied from xcape's author:
# Creating a spare modifier
spare_modifier="Hyper_L"
xmodmap -e "keycode 65 = $spare_modifier"
xmodmap -e "remove mod4 = $spare_modifier" # hyper_l is mod4 by default
xmodmap -e "add Control = $spare_modifier"
# Map space to an unused keycode (to keep it around for xcape to use).
xmodmap -e "keycode any = space"
# Finally use xcape to cause the space bar to generate a space when tapped.
xcape -t 175 -e "$spare_modifier=space;Control_L=Escape;Shift_L=parenleft;Shift_R=parenright" > /dev/null
Note that I also have a left Ctrl that's a dual role key with Esc and that the two Shift are dual role keys with open and closing parenthesis respectively (useful for Lisp and Emacs Lisp, where parentheses dominate).
This unconventional setup works better than it sounds, and even with all its problems I don't miss the TECK when I use my notebook.
Unfortunately xcape doesn't work on Wayland, so I've started to write something similar for it, but I'm not in a rush because Emacs doesn't run natively on it.
To summarize: symmetrical keyboards with dual modifiers are ideal for Emacs, but when mobility matters, dual role keys offer a reasonable compromise that respects proper typing ergonomics.
Yes, I'm aware "Considered Harmful" is itself considered harmful in computer science literature. At the date of writing, Google Scholar reports over one thousand results with this phrase in the title. Ironically, none titled "Considered Harmful Considered Harmful". ↩
the process of pressing a modifier key and a normal key to type a different character, like a musical instrument chord ↩
on a terminal I habitually use Ctrl-m instead of Enter ↩
damn you Dell, would have cost too much having two more keys? ↩