Take notes on " Narrow" nit

Commit might be somewhat incoherent; laptop power chord
stopped working so I willm push stuff out and delay thinking
until later

1 files changed, 113 insertions, 2 deletions

diff --git a/personal/itches.md b/personal/itches.md
index 2c1b295..e812276 100644
--- a/personal/itches.md
+++ b/personal/itches.md
@@ -39,12 +39,24 @@
   that icomplete-exhibit calls completion-pcm--filename-try-filter
   while icomplete-force-complete-and-exit simply calls
   minibuffer-force-complete-and-exit.
+- minor-mode to automatically surround word with delimiter when typed
+  in the middle of a word
+- customize " Compiling" mode-line indicator
 
 [bug#30008]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30008
 
 ## Make " Narrow" lighter customizable
 
-The " Narrow" string comes from `src/xdisp.c:decode_mode_spec`.
+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:
 
@@ -96,7 +108,7 @@ defining the variable with `DEFVAR_LISP`: e.g. `shell-file-name` is
 Mmm.  Not in `cus-start.el`.  There is this snippet in
 `callproc.c:init_callproc`:
 
-  ``` C
+  ``` c
   sh = getenv ("SHELL");
   Vshell_file_name = build_string (sh ? sh : "/bin/sh");
   ```
@@ -105,6 +117,105 @@ 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?
+
+… 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.
+
+   Note we operate on the current buffer for most purposes.  */
+
+```
+
+### Dumb questions
+
+- which Custom group(s) should this go into?
+
 ## Better out-of-the-box display for FORM FEED
 
 By default, FORM FEED is displayed as a dumb `^L` glyph.  This is