Are you familiar with dwm's powerful tag feature?
THE TAGGING MODEL
Many desktop environments organize windows using rigid workspaces:
Workspace 1
Workspace 2
Workspace 3
A window belongs to a single workspace.
dwm uses a different model, treating workspaces as bitmask labels (tags).
This allows a single window instance to hold multiple tags simultaneously,
acting as a persistent visual anchor across different contexts:
Firefox -> Tag 1 (Web Browsing)
st (nvi/dev) -> Tag 2 (Code/Scripts)
st (Monitor/Logs) -> Tag 1 + Tag 2 (Persistent)
When you view Tag 1, you see your browser and the log monitor. When you
switch to Tag 2, the browser disappears, but the exact same log window
remains on screen, now sharing space with your text editor.
The application is never duplicated or restarted in memory.
The UI remains minimal while enabling workflows that are difficult to
express using traditional workspace-oriented desktops.
Two decades later, this tagging model remains one of the most
distinctive features of dwm.

#suckless #dwm #unix #linux #sysadmin

Someone in IRC asked when dwm would be rewritten in a memory-safe language.

I think we're only a few decades away:

"First rewrite Xlib, Xft, and all the Linux kernel dependencies." :)

#suckless #dwm #linux

Für ein (nerd) Date möchte ich ein Vortrag über die Sentinel Satelliten aka Copernicus halten.
Werde es mit sent ( https://tools.suckless.org/sent/ ) vorbereiten. #suckless

a (sort of) #suckless case for #Wayland
https://wayland.fyi/

Just installed #OpenBSD on my #Thinkpad #X60 - a very old #32bit laptop. Works fine, still usable for everything except web browsing. OpenBSD has no #firefox or #Chromium in the official repos. For modern web browsing #Dillo or #Netsurf just can't handle the job. I use #suckless #surf web browser but it crashes very often 

Lol, #suckless st turned down a bidirectional text support patch. I mean, it’s quite expected, but still disappointing 🤷

Spent the day exploring heirloom-ex-vi (n-t-roff). It's
essentially the cleaned-up 1985 ex/vi 3.7 code, brought
forward by Gunnar Ritter and Carsten Kunze: small, simple,
and very readable — about 25k LOC for the editor itself,
versus 38k for nvi. The memory footprint is lower too,
around 3MB RSS against nvi's 6MB in typical use, and it
feels snappy in daily use.

The limits are by design rather than oversight. Fixed
temp-file blocks and a line-pointer table capped at
LBLKS=900 in the default build give you about 230k lines,
or roughly 30MB of text. Beyond that, you get the classic
"Tmp file too large" — and that's fine, because a screen
editor isn't the right tool for huge files anyway.

Trade-offs worth knowing: no set ruler, single-level
undo, and a hard ceiling on file size. nvi is more
practical for daily work, especially if you live in YAML
where column awareness matters. But heirloom is closer to
the original, and the codebase is genuinely beautiful.
Worth a look.

For anyone curious about the details, I keep a longer note
on heirloom-ex-vi here:

https://repo.or.cz/code-notes.git/blob_plain/HEAD:/notes/Exploring_Heirloom_ex_vi.txt.

Updated today with the LARGEF rebuild instructions for
files beyond the default ceiling.

#vi #unix #suckless #nvi