Organize itches into a folder hierarchy

Maybe having subfolders dedicated to developing test cases and patches
will help.

4 files changed, 244 insertions, 246 deletions

diff --git a/README.md b/README.md
index eb5b189..8ef193a 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 # Peniblec's Memory Leaks
-## still reachable: 6998 words in 12 pages
+## still reachable: 7053 words in 14 pages
 
 Hi!  I am a software engineer interested in [a bunch of things].
 
diff --git a/personal/itches/bulk.md b/personal/itches/bulk.md
new file mode 100644
index 0000000..b05ca0a
--- /dev/null
+++ b/personal/itches/bulk.md
@@ -0,0 +1,34 @@
+# XFCE
+
+- xfwm: hide/remove titlebar/decorations
+
+# Spell checkers
+
+- update dictionaries?
+
+# Conky
+
+Cannot use `${eval $${somefunc ${gw_iface}}}` more than once:
+
+    conky.text = [[
+    ${eval ${gw_iface}}
+    ${eval ${gw_iface}}
+    ]]
+    ⇒
+    wlp20
+    (null)
+
+See [GitHub issue][conky-issue-461].  Partially fixed by this [pull
+request][conky-pull-571], which allows using both `*speedf` functions
+together; `*graph` functions still trigger the bug though, e.g. with:
+
+    ${goto 20}${upspeedf ${gw_iface}}KiB/s${goto 90}↑${goto 100}${upspeedgraph ${gw_iface} 12,0 678b8b ffffff -t}
+    ${goto 20}${downspeedf ${gw_iface}}KiB/s${goto 90}↓${goto 100}${downspeedgraph ${gw_iface} 12,0 678b8b ffffff -t}
+
+[conky-issue-461]: https://github.com/brndnmtthws/conky/issues/461
+[conky-pull-571]: https://github.com/brndnmtthws/conky/pull/571
+
+# Bunsenlabs
+
+- use https for sources.list files
+- manpages for bl-… utilities
diff --git a/personal/itches.md b/personal/itches/emacs/bulk.md
index 4e5dd67..9e33c20 100644
--- a/personal/itches.md
+++ b/personal/itches/emacs/bulk.md
@@ -82,216 +82,6 @@
 [bug#31586]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31586
 [Unicode conventions]: https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00961.html
 
-## Make " Narrow" lighter customizable
-
-The " Narrow" string comes from `src/xdisp.c:decode_mode_spec`:
-
-``` c
-case 'n':
-  if (BUF_BEGV (b) > BUF_BEG (b) || BUF_ZV (b) < BUF_Z (b))
-    return " Narrow";
-```
-
-This is probably just a matter of returning the contents of a Lisp
-variable instead of this constant string.
-
-TODO:
-
-1. get the string value of a variable in C
-2. define a customizable string variable
-3. write a news entry
-4. write a patch
-5. extra credits: display string properties
-
-### Get the string value of a variable in C
-
-`decode_mode_spec` has some relevant snippets:
-
-- Given a `Lisp_Object obj`, `SSDATA(obj)` gives the string value as a
-  `char*`.
-
-- How to get a variable's `Lisp_Object`?
-    - `BVAR` works for buffer-local variables
-    - `V${lispname//-/_}`
-
-### Define a customizable string variable
-
-#### Defining variables visible to C code
-
-The C macro `DEFVAR_LISP(string-name, field-name)` does the following:
-
-    define a static `Lisp_Objfwd` variable v
-    get the address of globals._f##field-name &f
-
-    defvar_lisp(v, string-name, &f)
-
-As explained in the comments above `DEFVAR_LISP`, `globals` is a
-global variable defined in `globals.h`, which is "auto-generated by
-make-docfile" and exposes fields, `#define`s and `Lisp_Object`s for
-every global variable.
-
-make-docfile (`lib-src/make-docfile.c`) takes C files as input and
-searches all occurences of `^ +DEFSYM[ \t(]`, `^ +DEFVAR_[ILB]` or
-`^DEFU`, analyses what comes after and generates appropriate
-definitions for `globals.h`.
-
-`defvar_lisp` allocates a symbol using `Fmake_symbol`.
-
-#### Making it customizable
-
-`lisp/cus-start.el` defines customizable properties of symbols defined
-by C code.
-
-AFAICT, there is no need to assign the default value right after
-defining the variable with `DEFVAR_LISP`: e.g. `shell-file-name` is
-`DEFVAR_LISP`ed in `src/callproc.c` and its default value is set in…
-Mmm.  Not in `cus-start.el`.  There is this snippet in
-`callproc.c:init_callproc`:
-
-  ``` c
-sh = getenv ("SHELL");
-Vshell_file_name = build_string (sh ? sh : "/bin/sh");
-  ```
-
-But when starting with `SHELL=rofl emacs -Q`, Custom says that the
-value "has been changed outside Customize".  Changed from what to
-what?
-
-`cus-start.el` may contain a hint:
-
-``` elisp
-;; Elements of this list have the form:
-;; …
-;; REST is a set of :KEYWORD VALUE pairs.  Accepted :KEYWORDs are:
-;; :standard - standard value for SYMBOL (else use current value)
-;; …
-```
-
-Except that nope, this does not work.  Giving `:standard " Narrow"`
-and looking at the variable in Custom yields
-
-    narrow-lighter: nil
-        [State]: CHANGED outside Customize. (mismatch)
-
-A better example might be `overlay-arrow-string`, whose default value
-is set right after `DEFVAR_LISP` by calling `build_pure_c_string`.
-
-Why `build_pure_c_string` and not `build_string`?  From "(elisp) Pure
-Storage":
-
-> Emacs Lisp uses two kinds of storage for user-created Lisp objects:
-> “normal storage” and “pure storage”.  Normal storage is where all
-> the new data created during an Emacs session are kept (see Garbage
-> Collection).  Pure storage is used for certain data in the preloaded
-> standard Lisp files—data that should never change during actual use
-> of Emacs.
->
-> Pure storage is allocated only while ‘temacs’ is loading the
-> standard preloaded Lisp libraries.  In the file ‘emacs’, it is
-> marked as read-only (on operating systems that permit this), so that
-> the memory space can be shared by all the Emacs jobs running on the
-> machine at once.
-
-"(elisp) Building Emacs" explains that "temacs" is the minimal Elisp
-interpreter built by compiling all C files in `src/`; temacs then
-loads Elisp sources and creates the "emacs" executable by dumping its
-current state into a file.
-
-### Debug stuff
-
-#### Unicode characters represented as octal sequences
-
-Trying to customize the new variable to any string with non-ASCII
-characters fails: they show up as sequences of backslash-octal codes.
-For some reason they show up fine in the Help and Custom buffers.
-
-Things to investigate:
-
-1. Should the `Lisp_Object` be created with something other than
-   `build_pure_c_string`? 🙅
-2. What does the code calling `decode_mode_spec` do with the returned
-   string? **🎉**
-3. (Does `SSDATA` make some transformation before returning the
-   string? 🤷)
-4. (Should a specialized Custom setter be defined? 🤷)
-
-##### Should the `Lisp_Object` be created with something other than    `build_pure_c_string`?
-
-Maybe this would work?
-
-``` c
-Vnarrow_lighter = make_multibyte_string(" Narrow", strlen(" Narrow"),
-                                        strlen(" Narrow)");
-```
-
-That looks too ugly though, let's try something else.
-
-Maybe `STRING_SET_MULTIBYTE(Vnarrow_lighter)` would help?
-
-*compiles and tries*
-
-… Nope, it does not.
-
-##### What does the code calling `decode_mode_spec` do with the returned string?
-
-``` c
-spec = decode_mode_spec (it->w, c, field, &string);
-multibyte = STRINGP (string) && STRING_MULTIBYTE (string);
-```
-
-*slowly turns around*
-
-*finds `string` standing right there with a blank stare*
-
-Gah!  How long have you been there?
-
-``` c
-/* Return a string for the output of a mode line %-spec for window W,
-   generated by character C.  […]  Return a Lisp string in
-   *STRING if the resulting string is taken from that Lisp string.
-   […] */
-static const char *
-decode_mode_spec (struct window *w, register int c, int field_width,
-                  Lisp_Object *string)
-{
-  Lisp_Object obj;
-  /* … */
-  obj = Qnil;
-  *string = Qnil;
-
-  switch (c)
-    {
-    /* … */
-    }
-
-  if (STRINGP (obj))
-    {
-      *string = obj;
-      return SSDATA (obj);
-    }
-  else
-    return "";
-}
-```
-
-Alright then:
-
-``` c
-case 'n':
-  if (BUF_BEGV (b) > BUF_BEG (b) || BUF_ZV (b) < BUF_Z (b))
-      obj = Vnarrow_lighter;
-  break;
-```
-
-#### Why do string properties not show up?
-
-🤷
-
-### Extra credit
-
-Maybe it would be simpler to have the narrowing lighter work like the
-" Compiling" lighter (cf. `compilation-in-progress` variable), i.e. adding an entry to `minor-mode-alist`.
-
 ## Better out-of-the-box display for FORM FEED
 
 By default, FORM FEED is displayed as a dumb `^L` glyph.  This is
@@ -472,38 +262,3 @@ Full disclosure
   (set-face-attribute 'org-level-1 nil :height 1.2)
   (find-file "README.org")
   ```
-
-# XFCE
-
-- xfwm: hide/remove titlebar/decorations
-
-# Spell checkers
-
-- update dictionaries?
-
-# Conky
-
-Cannot use `${eval $${somefunc ${gw_iface}}}` more than once:
-
-    conky.text = [[
-    ${eval ${gw_iface}}
-    ${eval ${gw_iface}}
-    ]]
-    ⇒
-    wlp20
-    (null)
-
-See [GitHub issue][conky-issue-461].  Partially fixed by this [pull
-request][conky-pull-571], which allows using both `*speedf` functions
-together; `*graph` functions still trigger the bug though, e.g. with:
-
-    ${goto 20}${upspeedf ${gw_iface}}KiB/s${goto 90}↑${goto 100}${upspeedgraph ${gw_iface} 12,0 678b8b ffffff -t}
-    ${goto 20}${downspeedf ${gw_iface}}KiB/s${goto 90}↓${goto 100}${downspeedgraph ${gw_iface} 12,0 678b8b ffffff -t}
-
-[conky-issue-461]: https://github.com/brndnmtthws/conky/issues/461
-[conky-pull-571]: https://github.com/brndnmtthws/conky/pull/571
-
-# Bunsenlabs
-
-- use https for sources.list files
-- manpages for bl-… utilities
diff --git a/personal/itches/emacs/narrow-lighter.md b/personal/itches/emacs/narrow-lighter.md
new file mode 100644
index 0000000..e5987b8
--- /dev/null
+++ b/personal/itches/emacs/narrow-lighter.md
@@ -0,0 +1,209 @@
+# Make " Narrow" lighter customizable
+
+The " Narrow" string comes from `src/xdisp.c:decode_mode_spec`:
+
+``` c
+case 'n':
+  if (BUF_BEGV (b) > BUF_BEG (b) || BUF_ZV (b) < BUF_Z (b))
+    return " Narrow";
+```
+
+This is probably just a matter of returning the contents of a Lisp
+variable instead of this constant string.
+
+TODO:
+
+1. get the string value of a variable in C
+2. define a customizable string variable
+3. write a news entry
+4. write a patch
+5. extra credits: display string properties
+
+## Get the string value of a variable in C
+
+`decode_mode_spec` has some relevant snippets:
+
+- Given a `Lisp_Object obj`, `SSDATA(obj)` gives the string value as a
+  `char*`.
+
+- How to get a variable's `Lisp_Object`?
+    - `BVAR` works for buffer-local variables
+    - `V${lispname//-/_}`
+
+## Define a customizable string variable
+
+### Defining variables visible to C code
+
+The C macro `DEFVAR_LISP(string-name, field-name)` does the following:
+
+    define a static `Lisp_Objfwd` variable v
+    get the address of globals._f##field-name &f
+
+    defvar_lisp(v, string-name, &f)
+
+As explained in the comments above `DEFVAR_LISP`, `globals` is a
+global variable defined in `globals.h`, which is "auto-generated by
+make-docfile" and exposes fields, `#define`s and `Lisp_Object`s for
+every global variable.
+
+make-docfile (`lib-src/make-docfile.c`) takes C files as input and
+searches all occurences of `^ +DEFSYM[ \t(]`, `^ +DEFVAR_[ILB]` or
+`^DEFU`, analyses what comes after and generates appropriate
+definitions for `globals.h`.
+
+`defvar_lisp` allocates a symbol using `Fmake_symbol`.
+
+### Making it customizable
+
+`lisp/cus-start.el` defines customizable properties of symbols defined
+by C code.
+
+AFAICT, there is no need to assign the default value right after
+defining the variable with `DEFVAR_LISP`: e.g. `shell-file-name` is
+`DEFVAR_LISP`ed in `src/callproc.c` and its default value is set in…
+Mmm.  Not in `cus-start.el`.  There is this snippet in
+`callproc.c:init_callproc`:
+
+  ``` c
+sh = getenv ("SHELL");
+Vshell_file_name = build_string (sh ? sh : "/bin/sh");
+  ```
+
+But when starting with `SHELL=rofl emacs -Q`, Custom says that the
+value "has been changed outside Customize".  Changed from what to
+what?
+
+`cus-start.el` may contain a hint:
+
+``` elisp
+;; Elements of this list have the form:
+;; …
+;; REST is a set of :KEYWORD VALUE pairs.  Accepted :KEYWORDs are:
+;; :standard - standard value for SYMBOL (else use current value)
+;; …
+```
+
+Except that nope, this does not work.  Giving `:standard " Narrow"`
+and looking at the variable in Custom yields
+
+    narrow-lighter: nil
+        [State]: CHANGED outside Customize. (mismatch)
+
+A better example might be `overlay-arrow-string`, whose default value
+is set right after `DEFVAR_LISP` by calling `build_pure_c_string`.
+
+Why `build_pure_c_string` and not `build_string`?  From "(elisp) Pure
+Storage":
+
+> Emacs Lisp uses two kinds of storage for user-created Lisp objects:
+> “normal storage” and “pure storage”.  Normal storage is where all
+> the new data created during an Emacs session are kept (see Garbage
+> Collection).  Pure storage is used for certain data in the preloaded
+> standard Lisp files—data that should never change during actual use
+> of Emacs.
+>
+> Pure storage is allocated only while ‘temacs’ is loading the
+> standard preloaded Lisp libraries.  In the file ‘emacs’, it is
+> marked as read-only (on operating systems that permit this), so that
+> the memory space can be shared by all the Emacs jobs running on the
+> machine at once.
+
+"(elisp) Building Emacs" explains that "temacs" is the minimal Elisp
+interpreter built by compiling all C files in `src/`; temacs then
+loads Elisp sources and creates the "emacs" executable by dumping its
+current state into a file.
+
+## Debug stuff
+
+### Unicode characters represented as octal sequences
+
+Trying to customize the new variable to any string with non-ASCII
+characters fails: they show up as sequences of backslash-octal codes.
+For some reason they show up fine in the Help and Custom buffers.
+
+Things to investigate:
+
+1. Should the `Lisp_Object` be created with something other than
+   `build_pure_c_string`? 🙅
+2. What does the code calling `decode_mode_spec` do with the returned
+   string? **🎉**
+3. (Does `SSDATA` make some transformation before returning the
+   string? 🤷)
+4. (Should a specialized Custom setter be defined? 🤷)
+
+#### Should the `Lisp_Object` be created with something other than    `build_pure_c_string`?
+
+Maybe this would work?
+
+``` c
+Vnarrow_lighter = make_multibyte_string(" Narrow", strlen(" Narrow"),
+                                        strlen(" Narrow)");
+```
+
+That looks too ugly though, let's try something else.
+
+Maybe `STRING_SET_MULTIBYTE(Vnarrow_lighter)` would help?
+
+*compiles and tries*
+
+… Nope, it does not.
+
+#### What does the code calling `decode_mode_spec` do with the returned string?
+
+``` c
+spec = decode_mode_spec (it->w, c, field, &string);
+multibyte = STRINGP (string) && STRING_MULTIBYTE (string);
+```
+
+*slowly turns around*
+
+*finds `string` standing right there with a blank stare*
+
+Gah!  How long have you been there?
+
+``` c
+/* Return a string for the output of a mode line %-spec for window W,
+   generated by character C.  […]  Return a Lisp string in
+   *STRING if the resulting string is taken from that Lisp string.
+   […] */
+static const char *
+decode_mode_spec (struct window *w, register int c, int field_width,
+                  Lisp_Object *string)
+{
+  Lisp_Object obj;
+  /* … */
+  obj = Qnil;
+  *string = Qnil;
+
+  switch (c)
+    {
+    /* … */
+    }
+
+  if (STRINGP (obj))
+    {
+      *string = obj;
+      return SSDATA (obj);
+    }
+  else
+    return "";
+}
+```
+
+Alright then:
+
+``` c
+case 'n':
+  if (BUF_BEGV (b) > BUF_BEG (b) || BUF_ZV (b) < BUF_Z (b))
+      obj = Vnarrow_lighter;
+  break;
+```
+
+### Why do string properties not show up?
+
+🤷
+
+## Extra credit
+
+Maybe it would be simpler to have the narrowing lighter work like the
+" Compiling" lighter (cf. `compilation-in-progress` variable), i.e. adding an entry to `minor-mode-alist`.