A content/posts/debugging-dwm.md

@@ -0,0 +1,574 @@ 
+---
+title: "Debugging dwm to fix an annoying bug"
+date: 2024-02-17T18:19:23+05:30
+draft: true
+description: "Me debugging my window manager and learning a bit about it. This post is going to be me going through the process of debugging."
+---
+
+I use [dwm](https://dwm.suckless.org) as my window manager and I always wanted to hack on it since I started using it. This is just going to be me explaining some parts of the dwm codebase that I understood while debugging an annoying issue I was facing with it and how I learnt to not be overwhelmed by the codebase.
+
+The annoying issue that I was facing with my dwm setup was related to a scratchpad patch. I use a scratchpad terminal using the [scratchpad patch](https://dwm.suckless.org/patches/scratchpad/). It gives me an extra tag called the scratchpad where I can have a floating terminal window wherever I want.
+
+Like this:
+
+
+{{< video src="https://m.prithu.dev/dwm-debug-1-scratchpad-demo.mp4" type="video/mp4" loop=true autoplay=true >}}
+
+I have [nnn](https://github.com/jarun/nnn) running in a tmux window (I usually
+have a tmux session called `scratchpad` for this) which let's me quickly browse and open
+files. I also have other tmux windows for quick commands or to note down
+something.
+
+{{< aside >}}
+
+### A little about dwm tags
+
+DWM has the concept of "tags" and not workspaces. Those numbers on the top-left are tags. A window can be part of one or more tags. It's a little confussing when coming from other window managers, but this concept makes sense when you start using it. Example, let's say I have browser window on tag 2 and 4, so when I move from 2 to 4 the browser window appears on both the tags. DWM also allows you look at two tags at the same time. Which means all the windows in tag 2 and 4 appear at the same time. Might seem very weird for someone coming from another window manager where the numbers usually represent a workspace. Tags are a different concept, they aren't workspaces.
+
+{{< /aside >}}
+
+## The Problem
+
+Now, the problem is when I launch programs from the `scratchpad`, they stick around in the scratchpad tag too, which shouldn't happen. This means that the image viewer window has the tags `1` and `6` set (6 is the internal number for the scratch tag). Now when I move to another tag. (Note: there is no such thing as "moving" to another tab, just that you set a tag visible or invisible) and open the scratchpad there (make `scratch` tag visible) the image viewer opens there as well. This is pretty annoying. The expected behaviour for me is I want the scratchpad to launch GUI applications on the tag "behind" the scratchpad (i.e the other tag that is visible along with the scratchpad)
+
+Here's a video of the problem (You can see how frustrated I am by the chaotic mouse movement at the end):
+
+{{< video src="https://m.prithu.dev/dwm-debug-2-scratchpad-problem.mp4" type="video/mp4" loop=true autoplay=true >}}
+
+The problem also occurred when I launch directly from the terminal like `mpv file.mp4 &`. So it wasn't something funny `nnn` was doing.
+
+This is when I decided to read the [source code of dwm](https://git.suckless.org/dwm/files.html). My first intuition was that I will have to look at the code that handles new windows being opened in the X server and how dwm handles them. 
+
+
+## Reading the source code
+
+```c
+int
+main(int argc, char *argv[])
+{
+	if (argc == 2 && !strcmp("-v", argv[1]))
+		die("dwm-"VERSION);
+	else if (argc != 1)
+		die("usage: dwm [-v]");
+	if (!setlocale(LC_CTYPE, "") || !XSupportsLocale())
+		fputs("warning: no locale support\n", stderr);
+	if (!(dpy = XOpenDisplay(NULL)))
+		die("dwm: cannot open display");
+	checkotherwm();
+	setup();
+#ifdef __OpenBSD__
+	if (pledge("stdio rpath proc exec", NULL) == -1)
+		die("pledge");
+#endif /* __OpenBSD__ */
+	scan();
+	run();
+	cleanup();
+	XCloseDisplay(dpy);
+	return EXIT_SUCCESS;
+}
+
+```
+
+Starting from the `main()` function We see some argument checks, check if we can open the X display, check for another wm running, etc. Then some function calls: 
+- `setup()` - sets up things for dwm like initializing monitor and allocating space for some structs.
+- `scan()` - Scans the X server for all windows there are. Goes through every window using the [`XQueryTree()`](https://tronche.com/gui/x/xlib/window-information/XQueryTree.html) function and calls `manage()` for each window it finds. This is when I skim through `manage()` a little. It seems to me in the first read that this function is actually responsible for "registering" an X window as a "client" of dwm. Ok, we'll come back to this later.
+- `run()` - function which is nice and small and has the main event loop. Let's explore this further:
+
+
+```c
+void
+run(void)
+{
+    XEvent ev;
+    /* main event loop */
+    XSync(dpy, False);
+    while (running && !XNextEvent(dpy, &ev))
+        if (handler[ev.type])
+            handler[ev.type](&ev); /* call handler */
+}
+  ``` 
+
+
+`handler` is an array of function pointers that maps an XEvent type (an int) to a function that handles an [`XEvent`](https://tronche.com/gui/x/xlib/events/structures.html) of that type.
+``` c
+static void (*handler[LASTEvent]) (XEvent *) = {
+	[ButtonPress] = buttonpress,
+	[ClientMessage] = clientmessage,
+	[ConfigureRequest] = configurerequest,
+	[ConfigureNotify] = configurenotify,
+	[DestroyNotify] = destroynotify,
+	[EnterNotify] = enternotify,
+	[Expose] = expose,
+	[FocusIn] = focusin,
+	[KeyPress] = keypress,
+	[MappingNotify] = mappingnotify,
+	[MapRequest] = maprequest,
+	[MotionNotify] = motionnotify,
+	[PropertyNotify] = propertynotify,
+	[ResizeRequest] = resizerequest,
+	[UnmapNotify] = unmapnotify
+};
+
+```
+To me, the ones that seemed of my interest were `Expose`, `MappingNotify`, `MapRequest`. Now I started to read about the different [XEvents](https://tronche.com/gui/x/xlib/events/types.html). `Expose` is an event produced when a part of window is visible. `MappingNotify` seems like something related to keyboard/pointer mapping, which is unrelated to windows spawning. At this point I had read a little about how one creates a window and "maps" it in X. X refers to Mapping a window as the actual process of drawing it on the screen. You can create a window, but not displayed yet. A call to `XMapWindow()` is what makes the window visible on the screen. From the [docs](https://tronche.com/gui/x/xlib/window/XCreateWindow.html) of `XCreateWindow()`:
+
+> The created window is not yet displayed (mapped) on the user's display. To display the window, call XMapWindow().
+
+And if you read further in the docs of `XMapWindow()` you find the XEvent [`MapRequest`](https://tronche.com/gui/x/xlib/events/structure-control/map.html) mentioned
+
+> The X server can report MapRequest events to clients wanting information about a different client's desire to map windows
+
+That's it! DWM "subscribes" to this event because it wants to know which windows it needs to be managing. Now, need to look at what `maprequest` handler does:
+
+```c
+void
+maprequest(XEvent *e)
+{
+	static XWindowAttributes wa;
+	XMapRequestEvent *ev = &e->xmaprequest;
+	Client *i;
+	if ((i = wintosystrayicon(ev->window))) {
+		sendevent(i->win, netatom[Xembed], StructureNotifyMask, CurrentTime, XEMBED_WINDOW_ACTIVATE, 0, systray->win, XEMBED_EMBEDDED_VERSION);
+		resizebarwin(selmon);
+		updatesystray();
+	}
+
+	if (!XGetWindowAttributes(dpy, ev->window, &wa))
+		return;
+	if (wa.override_redirect)
+		return;
+	if (!wintoclient(ev->window))
+		manage(ev->window, &wa);
+}
+```
+We see `manage()` here too! This function handles the `XMapRequestEvent` type. The `XMapRequestEvent` type has a window ID `window` which is accesses via `ev->window`.
+The window ID and the window attributes of the new window are passed to `manage()`
+
+The if block `if(!wintoclient(ev->window))` can be be read as - "If we don't already have this client being managed in one of the monitors then manage it".
+
+```c
+Client *
+wintoclient(Window w)
+{
+	Client *c;
+	Monitor *m;
+
+	for (m = mons; m; m = m->next)
+		for (c = m->clients; c; c = c->next)
+			if (c->win == w)
+				return c;
+	return NULL;
+}
+
+```
+
+
+Okay then! `manage()` is where it's at then. I mean, the clue is in the word "manage". It is a window "manager" we are dealing with after all.
+
+Here are the first few lines of the function.
+
+
+```c
+void
+manage(Window w, XWindowAttributes *wa)
+{
+	Client *c, *t = NULL;
+	Window trans = None;
+	XWindowChanges wc;
+
+	c = ecalloc(1, sizeof(Client));
+	c->win = w;
+	/* geometry */
+	c->x = c->oldx = wa->x;
+	c->y = c->oldy = wa->y;
+	c->w = c->oldw = wa->width;
+	c->h = c->oldh = wa->height;
+	c->oldbw = wa->border_width;
+
+	updatetitle(c);
+	if (XGetTransientForHint(dpy, w, &trans) && (t = wintoclient(trans))) {
+		c->mon = t->mon;
+		c->tags = t->tags;
+	} else {
+		c->mon = selmon;
+		applyrules(c);
+	}
+
+// ...
+// ...
+```
+
+`manage()` gets a `Window` type (which is an `unsigned long` type underneath) which is an id of the window. It also gets a `XWindowAttributes` type which is a structure defining several attributes like `x`, `y` coordinates, `width`, `height`, `border_width`, etc.
+Before we go further, let's see what a `Client` and a `Monitor` is:
+
+{{< aside >}}
+
+`Monitor` and `Client` are the main structs of the program. Monitors hold clients and a client is a representation of a window that dwm is currently managing.
+
+Monitor struct:
+```c
+struct Monitor {
+	char ltsymbol[16];
+	float mfact;
+	int nmaster;
+	int num;
+	int by;               /* bar geometry */
+	int ty;               /* tab bar geometry */
+	int mx, my, mw, mh;   /* screen size */
+	int wx, wy, ww, wh;   /* window area  */
+	unsigned int seltags;
+	unsigned int sellt;
+	unsigned int tagset[2];
+	int showbar, showtab, topbar, toptab;
+	Client *clients;
+	Client *sel;
+	Client *stack;
+	Monitor *next;
+	Window barwin;
+	Window tabwin;
+	int ntabs;
+	int tab_widths[MAXTABS];
+	const Layout *lt[2];
+};
+```
+
+Client struct:
+
+```c
+struct Client {
+	char name[256];
+	float mina, maxa;
+	int x, y, w, h;
+	int oldx, oldy, oldw, oldh;
+	int basew, baseh, incw, inch, maxw, maxh, minw, minh;
+	int bw, oldbw;
+	unsigned int tags;
+	int isfixed, isfloating, isurgent, neverfocus, oldstate, isfullscreen;
+	int fakefullscreen;
+	Client *next;
+	Client *snext;
+	Monitor *mon;
+	Window win;
+};
+```
+
+There's `selmon` and `mons` global static variables that live throughout the
+lifecycle of the program are one of the main variables of the program. `selmon`
+points to the current selected monitor where the user's cursor is and `mons`
+points to the first monitor. Ech monitor points to the next monitor in a linked
+list fashion.
+
+
+{{< /aside >}}
+
+We see that a new client structure gets allocated and its fields are populated with relevant info—some coming from `XWindowAttributes *wa` and some being calculated. At the end of the function we see a call to `attach(c)` which prepends the client to the linked list of clients of the monitor it's on. So this tells us the purpose of the function is indeed to create a client (which is just a window representation within dwm) and assign it to a monitor.
+
+```c
+void
+attach(Client *c)
+{
+	c->next = c->mon->clients;
+	c->mon->clients = c;
+}
+
+```
+
+
+
+Down in this function I see this line `selmon->tagset[selmon->seltags] &= ~scratchtag;`. `selmon` is the current selected monitor and is a global static variable of `Monitor` type.
+
+A `tagset` is an int set that uses an unsigned int and represents a set of the current selected tags of the monitor. Only one of the index of `tagset` is the current selected `tagset` which is pointed by `setltags` and the other is the previous set of selected tags.  This is to implement an Alt+Tab like functionality for switching between tags. The line `selmon->tagset[selmon->seltags] &= ~scratchtag;` is simply removing the scratchpad's tag from the tag set. `scratchtag` holds the value 32 (0b100000). I have 5 defined tags and scratchpad's tag is simply the 6th one. The line sounds to be as if telling we want to only have scratchpad in the scratchtag and no other window, which is also apparent by the lines that follow it: 
+
+```c
+    selmon->tagset[selmon->seltags] &= ~scratchtag;
+	if (!strcmp(c->name, scratchpadname)) {
+		c->mon->tagset[c->mon->seltags] |= c->tags = scratchtag;
+		c->isfloating = True;
+		c->x = c->mon->wx + (c->mon->ww / 2 - WIDTH(c) / 2);
+		c->y = c->mon->wy + (c->mon->wh / 2 - HEIGHT(c) / 2);
+	}
+
+```
+Only if the new window has a title of "scratchpad" (value of `scratchpadname`) do we allow it to have the scratchpad tag.
+By removing the scratchpad tag before a new window is being mapped (wants to be displayed), the patch author made sure that the scratchtag is is not active when a new window comes in as we don't want any other window in the scrath tag other than the one that's named "scratchpad" and I think it's there exactly for the reason for the problem I am facing so that we don't get a new window in the scratch tag as well, then why does that still happen?
+
+## Firing up the GNU debugger
+Now, this is a big function and it's not easy to understand what's going on by just reading the code. We need to be able to debug dwm and be able to step over the code as dwm runs. So I started looking at how we could debug dwm and I learnt about [Xephyr](https://wiki.archlinux.org/title/Xephyr). Xephyr is a nested X server that runs as an X application. It would allow me to start another X server and run dwm on it and then I could debug dwm.
+
+
+Now to debug it we need to compile dwm with debugging enabled so that gdb can look up symbols and make debugging easy. Adding the `-g` in `CFLAGS` in `config.mk`:
+
+```diff
+-CFLAGS   = -std=c99 -pedantic -Wall -Wno-deprecated-declarations -Os ${INCS} ${CPPFLAGS}
++CFLAGS   = -g -std=c99 -pedantic -Wall -Wno-deprecated-declarations -Os ${INCS} ${CPPFLAGS}
+
+```
+
+```
+$ Xephyr -br -ac -noreset -screen 800x600 :2 &
+$ export DISPLAY=:2
+$ make
+$ gdb ./dwm
+``` 
+
+This would run dwm in the Xephyr X server as an X application. I think this is pretty cool!
+Now as usual we can setup breakpoints and step through the code.
+
+Here's a video of me reproducing the same problem with Xephyr and gdb
+
+{{< video src="https://m.prithu.dev/dwm-debug-3-dwm-xephyr-gdb.mp4" type="video/mp4" loop=true autoplay=true >}}
+
+
+
+First I want to confirm whether the new window being launched when the scratchpad is open, does have the scratchpad tag. From the Xephyr X instance, I open a scratchpad and run `eog ~/pictures/someimage.jpg` from the scratchpad terminal. I then send a SIGINT by pressing Ctrl-C in gdb window to get a gdb prompt. We can see now print the `selmon->clients->tags` value. Which will show us the tags of the last spawned window—the latest client managed under dwm. 
+
+```
+GNU gdb (GDB) 14.1
+Copyright (C) 2023 Free Software Foundation, Inc.
+Reading symbols from ./dwm...
+(gdb) run
+Starting program: /home/prithu/src/dwm/dwm
+
+
+^C
+Program received signal SIGINT, Interrupt.
+0x00007ffff7cfff44 in poll () from /usr/lib/libc.so.6
+(gdb) print(*selmon->clients)
+$2 = {name = "20230903_153036.jpg", '\000' <repeats 236 times>, mina = 0, maxa = 0, x = 0, y = 16, w = 800, h = 584, oldx = 163, oldy = 43, oldw = 474, oldh = 514, basew = 360, baseh = 350, incw = 0, inch = 0, maxw = 0, maxh = 0,
+  minw = 437, minh = 350, bw = 0, oldbw = 0, tags = 33, isfixed = 0, isfloating = 0, isurgent = 0, neverfocus = 0, oldstate = 0, isfullscreen = 0, fakefullscreen = 0, next = 0x55555564ae90, snext = 0x55555564ae90, mon = 0x5555555d0a40,
+  win = 6291463}
+(gdb) print(selmon->clients->tags)
+$3 = 33
+
+```
+
+
+
+And yes, indeed we do see the value 33 (0b100001) which means that the client is on the scratchpad tag (0b100000) and tag 1 (0b000001). Now to find out why does that happen even though we have the line `selmon->tagset[selmon->seltags] &= ~scratchtag;` as a failsafe which makes sure we don't spawn any windows in the scratch tag? Well this is where stepping through the code line by line will help. We need to  check the value of `c->tags` and what changes it during the run.
+
+I open a new debug session and set a breakpoint at the line `c = ecalloc(1, sizeof(Client));` in `manage()`. When a new window is created (mapped) by launching a GUI application, we should hit the breakpoint as dwm tries to add the window in the list of managed clients. I open a scratchpad again and the breakpoint is hit, because the and run `eog ~/pictures/someimage.jpg` and this time we hit the breakpoint once for scratchpad terminal when It spawns for the first time; I just `continue`, and the second time the breakpoint is hit for the launch of the `eog` window.
+
+
+```
+
+~/src/dwm (mybuild) › gdb ./dwm
+GNU gdb (GDB) 14.1
+Copyright (C) 2023 Free Software Foundation, Inc.
+Reading symbols from ./dwm...
+(gdb) b dwm.c:1305
+Breakpoint 1 at 0xa2c0: file dwm.c, line 1306.
+(gdb) run
+Starting program: /home/prithu/src/dwm/dwm
+
+This GDB supports auto-downloading debuginfo from the following URLs:
+  <https://debuginfod.archlinux.org>
+Enable debuginfod for this session? (y or [n]) y
+[Detaching after fork from child process 4106464]
+```
+```
+
+Breakpoint 1, manage (w=4194310, wa=0x555555564020 <wa>) at dwm.c:1306
+1306            c = ecalloc(1, sizeof(Client));
+(gdb) c
+Continuing.
+```
+
+We hit the first breakpoint. This is when I launch the scratchpad for the first time. That's when the terminal window is created.
+```
+
+Breakpoint 1, manage (w=6291463, wa=0x555555564020 <wa>) at dwm.c:1306
+1306            c = ecalloc(1, sizeof(Client));
+(gdb) n
+1309            c->x = c->oldx = wa->x;
+```
+The second breakpoint is hit when I launch `eog ~/pictures/somepic.jpg &`. The first line (1306) simply allocates space for the new client.
+```
+(gdb) display c->name
+1: c->name = '\000' <repeats 255 times>
+(gdb) display c->tags
+2: c->tags = 0
+(gdb) display selmon->tagset
+3: selmon->tagset = {33, 2}
+```
+I use the `display` command here (Which I learnt in this process) to always print the values I am interested in after each line executes—`c->name` (Name of the client:X Window title), `c->tags`(The tags the client get's assigned, `selmon->tagset` (The current active tags of the current selected monitor: recall that the new window gets assigned the tags of the scratchpad and the tag that is active along with the scratchpad too)
+
+```
+(gdb) n
+1310            c->y = c->oldy = wa->y;
+1: c->name = '\000' <repeats 255 times>
+2: c->tags = 0
+3: selmon->tagset = {33, 2}
+(gdb) n
+1311            c->w = c->oldw = wa->width;
+1: c->name = '\000' <repeats 255 times>
+2: c->tags = 0
+3: selmon->tagset = {33, 2}
+(gdb) n
+1312            c->h = c->oldh = wa->height;
+1: c->name = '\000' <repeats 255 times>
+2: c->tags = 0
+3: selmon->tagset = {33, 2}
+(gdb) n
+1313            c->oldbw = wa->border_width;
+1: c->name = '\000' <repeats 255 times>
+2: c->tags = 0
+3: selmon->tagset = {33, 2}
+```
+In the above lines, the client gets assigned a few attributes like window position, height and width from the XWindowAttributes
+```
+(gdb) n
+1315            updatetitle(c);
+1: c->name = '\000' <repeats 255 times>
+2: c->tags = 0
+3: selmon->tagset = {33, 2}
+(gdb) n
+1316            if (XGetTransientForHint(dpy, w, &trans) && (t = wintoclient(trans))) {
+1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
+2: c->tags = 0
+3: selmon->tagset = {33, 2}
+```
+After the `updatetitle(c)` we see that the name of the client changed. `updatetitle(c)` lives upto its name!
+
+```
+(gdb) n
+1320                    c->mon = selmon;
+1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
+2: c->tags = 0
+3: selmon->tagset = {33, 2}
+```
+`c->mon = selmon` assigns the monitor it goes on (which is the current monitor)
+
+```
+(gdb) n
+1321                    applyrules(c);
+1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
+2: c->tags = 0
+3: selmon->tagset = {33, 2}
+(gdb) n
+1324            if (c->x + WIDTH(c) > c->mon->mx + c->mon->mw)
+1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
+2: c->tags = 33
+3: selmon->tagset = {33, 2}
+```
+And here we have it, our culprit! After the call to `applyrules(c)` we have c->tags change value to `selmon->tagset[selmon->seltags]` which is 33 (`0b100001`)
+
+```
+(gdb) n
+1326            if (c->y + HEIGHT(c) > c->mon->my + c->mon->mh)
+1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
+2: c->tags = 33
+3: selmon->tagset = {33, 2}
+(gdb) n
+1328            c->x = MAX(c->x, c->mon->mx);
+1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
+2: c->tags = 33
+3: selmon->tagset = {33, 2}
+(gdb) n
+1330            c->y = MAX(c->y, ((c->mon->by == c->mon->my) && (c->x + (c->w / 2) >= c->mon->wx)
+1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
+2: c->tags = 33
+3: selmon->tagset = {33, 2}
+(gdb) n
+1334            selmon->tagset[selmon->seltags] &= ~scratchtag;
+1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
+2: c->tags = 33
+3: selmon->tagset = {33, 2}
+(gdb) n
+1335            if (!strcmp(c->name, scratchpadname)) {
+1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
+2: c->tags = 33
+3: selmon->tagset = {1, 2}
+```
+
+We don't enter the scratchpad loop because this isn't a scratchpad window. It's
+eog image viewer. The line `selmon->tagset[selmon->seltags] &= ~scratchtag` is
+too late. The client has already been assigned the scratchpad tag.
+
+```
+(gdb) n
+1342            wc.border_width = c->bw;
+1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
+2: c->tags = 33
+3: selmon->tagset = {1, 2}
+(gdb)
+...
+...
+```
+And as I go through the whole function, I find that `c->tags` isn't changed anywhere else.
+
+I learnt about the `display` command in this process which I thought what `watch` actually was. `watch` breaks when a variable's value changes, while display just prints the value of the variable after each step.
+
+TL;DR
+There's a function `applyrules(c)` that takes `Client` type add modifies the client `c`—which I completely skipped over while reading the code. I didn't bother to look at what it did. But when I saw the value change, everything clicked! The `c->tags` value was being changed by `applyrules(c)` way before the line `selmon->tagset[selmon->seltags] &= ~scratchtag` is executed. I took a look at `applyrules(c)` but already guessed what it does. It is responsible for applying some rules to the new client but also adds tags to new clients, which I didn't suspect during my first read. 
+
+
+```c
+void
+applyrules(Client *c)
+{
+	const char *class, *instance;
+	unsigned int i;
+	const Rule *r;
+	Monitor *m;
+	XClassHint ch = { NULL, NULL };
+	c->isfloating = 0;
+	c->tags = 0;
+	XGetClassHint(dpy, c->win, &ch);
+	class    = ch.res_class ? ch.res_class : broken;
+	instance = ch.res_name  ? ch.res_name  : broken;
+
+	for (i = 0; i < LENGTH(rules); i++) {
+		r = &rules[i];
+		if ((!r->title || strstr(c->name, r->title))
+		&& (!r->class || strstr(class, r->class))
+		&& (!r->instance || strstr(instance, r->instance)))
+		{
+			c->isfloating = r->isfloating;
+			c->tags |= r->tags;
+			for (m = mons; m && m->num != r->monitor; m = m->next);
+			if (m)
+				c->mon = m;
+		}
+	}
+	if (ch.res_class)
+		XFree(ch.res_class);
+	if (ch.res_name)
+		XFree(ch.res_name);
+	c->tags = c->tags & TAGMASK ? c->tags & TAGMASK : c->mon->tagset[c->mon->seltags];
+}
+
+```
+
+
+`applyrules()` does some rule matching which is a feature that comes default in dwm config, where you can specify rules for specific windows. For example, let's say you wanted the Gimp Window to always open in tag 2—that sort of thing. We don't have any rules setup for the eog file viewer so this shouldn't affect it? Right? But, in `applyrules(c)` we see that `c->tags` is actually set to 0 first and then at the very end (after gone through the rules), it actually sets the tags if `c->tags` isn't already set by any of rules. The line `c->tags = c->tags & TAGMASK ? c->tags & TAGMASK : c->mon->tagset[c->mon->seltags];` reads "If there are no tags set yet for this client, then set them to the same tagset the client's monitor has" so the client's tags equal `c->mon->tagset[c->mon->seltags]` and we know that `c->mon` is `selmon` from the caller function just before the call to `applyrules()`— `c->mon = selmon`
+
+There's the problem and the solution is put this assignment `selmon->tagset[selmon->seltags] &= ~scratchtag` before the call to `applyrules()`. That's it!
+
+All this to get this diff:
+
+```diff
+@@ -1304,6 +1313,11 @@ manage(Window w, XWindowAttributes *wa)
+ 	c->oldbw = wa->border_width;
+ 
+ 	updatetitle(c);
++	selmon->tagset[selmon->seltags] &= ~scratchtag;
+ 	if (XGetTransientForHint(dpy, w, &trans) && (t = wintoclient(trans))) {
+ 		c->mon = t->mon;
+ 		c->tags = t->tags;
+    } else {
+        c->mon = selmon;
+        applyrules(c);
+    }
+@@ -1322,7 +1332,6 @@ manage(Window w, XWindowAttributes *wa)
+ 		&& (c->x + (c->w / 2) < c->mon->wx + c->mon->ww)) ? bh : c->mon->my);
+ 	c->bw = borderpx;
+ 
+-	selmon->tagset[selmon->seltags] &= ~scratchtag;
+ 	if (!strcmp(c->name, scratchpadname)) {
+ 		c->mon->tagset[c->mon->seltags] |= c->tags = scratchtag;
+ 		c->isfloating = True;
+
+```
+
+## What I learnt
+-