xlsatoms

Atoms are the X protocol's way of not sending strings: a name is interned once with InternAtom and gets a 32-bit number that is then used in properties, selections and ClientMessage. Jim Fulton's xlsatoms from 1989 walks the table with GetAtomName from number 1 upward until the server answers with an error, printing number and name. The first 68 are fixed by the protocol and identical on every server — PRIMARY is 1, ATOM is 4, WM_COMMAND 34, WM_CLIENT_MACHINE 36 and WM_TRANSIENT_FOR 68 — so clients need not ask for them; after that comes everything any client has created since the server started, in the order it happened. -range 60-70 picks an interval, -name _NET_WM_PID does a lookup from the shell and reports an error if the atom does not exist, and -format shapes the output with printf syntax.

The list is an archaeological section. The core protocol has no request for deleting an atom, so every name lives until the server restarts, whether or not the client that created it vanished weeks ago. On an ordinary desktop a week or so of uptime yields a couple of thousand lines, with the GDK_ and _NET_ names usually the two largest groups, and you can read off which toolkits, window managers and extensions have passed through. That makes xlsatoms the tool for finding atom leaks: a program that interns a new, unique name per window or per tooltip fills the server's table until someone wonders why X is eating memory, and xlsatoms | wc -l before and after gives it away in a minute.