Seventeen years and running. Happy hacking!

I know about the sophisticated mail-deduplicate utility, but I guess it's too sophisticated for me :) Turns out the solution was in front of my eyes: notmuch knows about duplicates, and can list them easily:

notmuch search --duplicate=2 --output=files '*'`

That command will list the full path to the second file in duplicate pairs found by notmuch. So, getting rid of them is as easy as

for f in  `notmuch search --duplicate=2 --output=files '*'``; do
  rm $f;
done
notmuch new

After doing that (note we rebuild notmuch's database at the end, searching again for level-2 duplicates might discover new files if you have emails duplicated more than twice (i had). Rinse and repeat.

Here's a quick'n'dirty command to generate an org-mode rendering of an eww page, taking into account not only links (as the built-in org-eww-copy-for-org-mode does), but also headings, italic and bold faces.

I am pretty sure it's full of corner cases and rough edges, but it's working for me as a starting point.

(defun jao-eww-to-org (&optional dest)
  "Render the current eww buffer using org markup.
If DEST, a buffer, is provided, insert the markup there."
  (interactive)
  (unless (org-region-active-p)
    (let ((shr-width 80)) (eww-readable)))
  (let* ((start (if (org-region-active-p) (region-beginning) (point-min)))
         (end (if (org-region-active-p) (region-end) (point-max)))
         (buff (or dest (generate-new-buffer "*eww-to-org*")))
         (link (eww-current-url))
         (title (or (plist-get eww-data :title) "")))
    (with-current-buffer buff
      (insert "#+title: " title "\n#+link: " link "\n\n")
      (org-mode))
    (save-excursion
      (goto-char start)
      (while (< (point) end)
        (let* ((p (point))
               (props (text-properties-at p))
               (k (seq-find (lambda (x) (plist-get props x))
                            '(shr-url image-url outline-level face)))
               (prop (and k (list k (plist-get props k))))
               (next (if prop
                         (next-single-property-change p (car prop) nil end)
                       (next-property-change p nil end)))
               (txt (buffer-substring (point) next))
               (txt (replace-regexp-in-string "\\*" "·" txt)))
          (with-current-buffer buff
            (insert
             (pcase prop
               ((and (or `(shr-url ,url) `(image-url ,url))
                     (guard (string-match-p "^http" url)))
                (let ((tt (replace-regexp-in-string "\n\\([^$]\\)" " \\1" txt)))
                  (org-link-make-string url tt)))
               (`(outline-level ,n)
                (concat (make-string (- (* 2 n) 1) ?*) " " txt "\n"))
               ('(face italic) (format "/%s/ " (string-trim txt)))
               ('(face bold) (format "*%s* " (string-trim txt)))
               (_ txt))))
          (goto-char next))))
    (pop-to-buffer buff)
    (goto-char (point-min))))

It took me twenty or thirty pages to really enter in this book, but once I got in its mood I had a truly great time. It includes a subliminal tour over classic literature, painting and philosophy all in a truy original narrative voice. Foster Wallace's afterword has also some interesting bits, once you pardon him his pretentiousness (definitely a much better writer than critic). And remember, the protagonist is not called Helen.

Vargas Llosa's political views are so obnoxious that I've been putting off reading him for decades out of contempt. But one of my teachers insisted I should forget about politics and read this one, or La fiesta del chivo, and I finally took the plunge. And I must say I am happy I did: the way Vargas Llosa plays with language in La casa verde is astounding, and he's able to do things I would have thought impossible. Reminded me of that scene in the movie Amadeus where Mozart explains to the king how three or four people talking at once is just noise, but four voices singing at once is harmony and beauty. Well, Vargas Llosa does the same in writing. He's also able to play with time, interlocking two or three temporal lines in a single narrative and even making the whole thing at times loop into itself. The man knew how to write (I read his latest works are not as good as they used to be) and was creating something I've not seen any other writer do. I read afterwards La fiesta del chivo, which is good but not as good. All that in Spanish: I am not sure all those fireworks can be translated, but one would surely need a talented translator for them!

I've read good things about the forthcoming movie, and liked what I saw in the promotional video, but I cannot believe it's going to be near as good as this novel. The book has too many nuances, literary tricks and wordplay and paragraphs one has to read and reread, to be translated to a film. The latter might be its own work of art, and that's fine. But if you're curious about the movie, I'd definitely recommend to read this book. If you're not, I'd definitely recommend to read this book. The writing is fresh and funny, in typical Gray fashion, and the real themes of the book are universal and exposed in a way that is very entertaining on the surface, but with a subtext that gives you food for thought. I don't remember when was the last time that I read two hundred pages of a book in a single day, time just flew, as they say.

• Programming language semantics: It’s easy as 1,2,3
• No Silver Bullet - Essence and Accident in Software Engineering

Older entries

Physically, this book is obnoxious: huge, wasted margins frame a reproduction of the original text that painstakingly tries to look as shabby as it was, including faded letters and all its typos, and its size and weight border on the unmanageable. Ah, but the contents is really good: on the one hand there's of course Joyce's text itself (after twenty years since the last time, my English, with the help of the annotations, was closer to be up to the task, and enjoy it even when it wasn't), and next to it the essays introducing every chapter, which i found (with an exception or two) very informative and, sometimes, even illuminating. I was also delighted to confirm that the parallels with Homer's work are a strecht to say the least: i quickly read The Odyssey in preparation and found it, again, boring at best and disheartening in its depiction of the society of the time (not that Joyce's Dublin was without its blemishes, but you hopefully get my point).

So, just get an electronic version and enjoy!

This is a beautiful book. Crystal-clear and insightful explanations, with the right amount of historical background and quite original outlook (without going overboard). I can only echo what other quoted reviewers have said: i wish i had had this book when i was studying these matters in earnest, i'm pretty sure i've understood some fine points for the first time only now! I'd also perhaps make an exception on the last part (or act, as Needham calls them) on differential forms, which feels at times a bit rushed and in need of some editing, and it'd had been wonderful if the manufacture of the book were up to its contents: most images and photographs look really, really cheap, and there are more typos than granted, which is a pity (as to other figures, they're decent, although it must be said that Needham is not Penrose, but then who is?).

and inline snippets:

Happy searches!

A very interesting view of how a biographer started her career in the seventies, with two heavy-weights, Beckett and de Beauvoir. Bair calls the book a bio-memoir, and it's indeed quite deserving of a name of its own for its genre. One learns of the struggle it was not only to be a biographer of famous writers still living (and her fascinating relationship with them) but also to be a successful woman in the seventies. And there are lots of interesting details about her writing process, and its all too human side. Very well written all around, it really whets your appetite: i've already ordered her Beckett bio!

Recoll is a local search engine that knows how to index a wide variety of file formats. It also offers a sophisticated query language, and, for some document kinds, snippets of the text of the document that actually match your query: that's always been one of my favourite features, and wanted to bring it to emacs.

i found consult's live previews a very nice venue to bring snippets into emacs, via a new version of consult-recoll, and there you go, just a small matter of programming¹.

There are several things of this package that make me happy. For one, it's very small (less than 200 lines of code, including comments) and does quite a bit, thanks to the help of consult on the emacs side and of recoll on the system's side. In my opinion, it's a very good example of how the operative environment provided by emacs brings the Unix philosophy to the next level: here, it's gluing together functionality provided by emacs packages (completing read, consult's asynchronous searches and previews, and so on), and the indexing and search capabilities of a totally unrelated, orthogonal program, recoll, which in turn delegates to a swarm of other unix programs (such as antiword, unrtf, poppler, pstotext and a long etc) to extract information from local files². Very pleasant!

A nicely written (as always with Ishiguro) history of Stevens turned into an artificially intelligent being, in a near future reminiscent of Never let me go. In other words, i found this novel heavily inspired in previous works of the author, which i admittedly find better than this one, but that doesn't mean the book doesn't throw at you a bunch of provocative musings or lacks a tranquil beauty that makes it absolutely worth reading.

I've had in mind writing a brief note on my notes utilities for a while, so i guess this is a good time for it: i can, after showing you mine, point you to a polished package following a similar philosophy and sidestep any temptation of doing anything similar with my little functions :)

As you'll see in a moment, in some ways, my note taking system is even simpler than Prot's, while in others i rely on more sophisticated software, essentially meaning that where denote is happy to use dired and filenames, i am using grep over the front-matter of the notes. So if you loved the filename-as-metadata idea in denote, you can skip the rest of this post!

These are the main ideas around which i built my note-taking workflow:

• Personally, i have such a dislike for non-human readable identifiers, that i cannot even stand those 20221234T142312 prefixes (for some reason, i find them quite hard to read and distracting). When i evolved my notes collection, i wanted my files to be named by their title and nothing more. I am also pretty happy to limit myself to org-mode files. So i wanted a directory of (often short) notes with names like the-lisp-machine.org, david-foster-wallace.org or combinator-parsing-a-short-tutorial.org.¹
• I like tags, so all my notes, besides a title, are going to have attached a list of them (denote puts them in the filename and inside the file's headers; i'm content with the latter, because, as you'll see in a moment, i have an easy way of searching through that contents).
• I'm not totally averse to hierarchies: besides tagging, i put my notes in a subdirectory indicating their broad category. I can then quickly narrow my searches to a general theme if needed².
• As mentioned, i want to be able to search by the title and tag (besides more broadly by contents) of my notes. Since that's all information available in plain text in the files, grep and family (via their emacs lovely helpers) are all that is needed; but i can easily go a step further and use other indexers of plain text like, say, recoll (via my consult-recoll package).
• It must be easy to quickly create notes that link to any contents i'm seeing in my emacs session, be it text, web, pdf, email, or any other. That comes for free thanks to org and org-capture.
• I want the code i have to write to accomplish all the above to be short and sweet, let's say well below two hundred lines of code.

Turns out that i was able to write a little emacs lisp library doing all the above, thanks to the magic of org-mode and consult: you can find it over at my repo by the name of jao-org-notes.el. The implementation is quite simple and is based on having all note files in a parent directory (jao-org-notes-dir) with a subfolder for each of the main top-level categories, and, inside each of them, note files in org mode with a preamble that has the structure of this example:

#+title: magit tips
#+date: <2021-07-22 Thu>
#+filetags: git tips

The header above corresponds to the note in the file emacs/magit-tips.org. Now, it's very easy to write a new command to ask for a top-level category and a list of tags and insert a header like that in a new file: it's called jao-org-notes-open-or-create in my little lib, and with it one can define a new org template:

("N" "Note" plain (file jao-org-notes-open-or-create)
 "\n- %a\n  %i"
 :jump-to-captured t)

that one can then add to org-capture-templates (above, i'm using "N" as its shortcut; in the package, this is done by jao-org-notes-setup, which takes the desired shortcut as a parameter). I maintain a simple list of possible tags in the variable jao-org-notes--tags, whose value is persisted in the file denoted by the value jao-org-notes-tags-cache-file, so that we can remember newly-added tags; with that and the magic of emacs's completing read, handling tags is a breeze.

Now for search. These are text files, so if i want to search for contents, i just need grepping, for instance with M-x rgrep or, even better, M-x consult-ripgrep. That is what the command jao-org-notes-grep does.

But it is also very useful to be able to limit searches to the title and tags of the notes: that's what the command jao-org-notes-open does using consult and ripgrep by the very simple device of searching for regular expressions in the first few lines of each file that start with either #+title: or #+filetags: followed by the terms we're looking for. That's something one could already do with rgrep alone; what consult adds to the party is the ability of displaying the matching results nicely formatted:

Links between notes are simply org file: links, and having a simple "backlinks" command is, well, simple if you don't want anything fancy³. A command to insert a new link to another note is so boring to almost not meriting mention (okay, almost: jao-org-notes-insert-link).

And that's about it. With those simple commands and in about 160 lines of code i find myself comfortably managing plain text notes, and easily finding contents within them. I add a bit of icing by asking Recoll to index my notes directory (as well as my email and PDFs): it is clever enough to parse org files, and give you back pointers to the sections in the files, and then issue queries with the comfort of a consult asynchronous command thanks to consult-recoll (the screenshot in the introduction is just me using it). It's a nice use case of how having little, uncomplicated packages that don't try to be too sophisticated and center on the functionality one really needs makes it very easy to combine solutions in beatiful ways⁴.

During the last year, a perceived sluggishness in Emacs's X11 display performance, together with a very noticeably increased RAM consumption have become one of those irritants, and i decided that enough is enough, and moved (for the time being at least) from exwm to, essentially, using xmonad and kitty as my Emacs's display engine.

For several years now, i've been using exwm as my main desktop, and been quite happy with it. One of the reasons is that i almost don't get bit by blocking external programs because, well, i don't use many external programs. It's still a bit annoying when every now and then emacs gets stuck in a busy loop and i have to wait to regain control of my computer (since emacs is single threaded), and for that reason, i also have an xmonad configuration tailored to essentially use emacs for everything, with an occasional detour to a web browser or maybe a video player. That way, if emacs gets stuck, i can do something else, and, also, i don't need to restart my desktop when i recompile Emacs.

Before that, i had been using emacs as a daemon and emacsclient -t in an rxvt terminal as my primary emacs interface for many years. The limitations weren't many for my use cases: one cannot display images, but it's very easy to set up things so that one gets a, say, feh pop up when needed (which is not often) or open an eww buffer in Firefox instead; and one cannot display PDFs inside Emacs. That last one was harder, because i keep my notes (using a very simple library of mine) in org mode with links to PDFs and need to be able to easily go from one to the other. I found a good (for my needs) solution for the latter too, but well, running Emacs under X11 (or even under wayland in sway) also worked and was convenient, so i thoght my terminal days were just a fond memory.

Until a year or so ago, when i started noticing my X11 Emacs instance consuming considerably more RAM (as in, 5 times what it used to need for long running sessions… still more or less what a "modern" browser takes, i know, but i don't want my Emacs to resemble a browser in any way). I normally run Emacs compiled from master, so hiccups happen and i didn't panic: there probably was some accidental leak that would be fixed and i could even help locating it. Unfortunately, with the release of Emacs 28, this higher memory needs seem consolidated (and no, i don't use native compilation, so they don't come from there), as is the tendency to eat more memory as the session grows longer (without changes in my usage patterns, the RSS footprint of the process tends to increase at least 500Mb per day). And, even more unfortunately, i seem to be the only person on earth suffering from this: i haven't found yet any fellow emacser observing the problem, and, although i've tried, i couldn't find a single package (or combination thereof) causing this issue. Except, that is, for the X11 display mode.

Fact is, if i run emacs in a terminal with the same packages as normal and with the same usage patterns (which are essentially the same as when i use it in X11), there is no memory leak. Once i load the standard set of packages i use (chats, eww, notmuch, cider, that kind of thing, plush all my customizations), an X11 emacs will take around 500Mb RAM, while a terminal one is happy with 250Mb. And that's fair enough. Problem is, after 3 or 4 days using the X11 version, RAM is consumption jumping to 3 or 4 Gb, while a terminal-based emacs used in essentially the same way will typically be around 500Mb.

Thanks to the experiment above, i'm reasonably sure that the graphical interface is at the root of my memory woes. That by itself would have already been enough to seriously consider a return to my emacs daemon days, but there was more: using emacs in an X terminal after all this time, really made me realize how slow the rendering in X11 Emacs is by comparison. I mean, rendering in X11 is not slow in absolute terms, it's perfectly usable in my experience; but, in a terminal? let me tell you, it's fast, an a real pleasure to use.

So all i needed was to smooth out a few wrinkles and it'd be a done deal. First thing was to try with kitty as terminal emulator, just because it's the one i use these days and i like how it's developed. It took a bit of wrestling to make sure that my usual keybindings (or slight modifications of them) would work, and also some documentation reading to come up with a good configuration, but it wasn't too hard: you can find my kitty.conf here. A point worth making is that running Emacs with kitty as a graphical frontend is, for practical purposes, very close to running Emacs in "graphical mode"; for instance, kitty has background transparency, uses the same font rendering engine (HarfBuzz) as X11 Emacs, and it's perfectly able to display things like emojis; it just does all that faster! One only needs to get rid of the discontinuous vertical separators in Emacs:

(set-display-table-slot standard-display-table 'vertical-border (make-glyph-code ?│))

and also clean up the end of the modeline:

(setq mode-line-end-spaces nil)

and then you get the screenshot above of some random buffers in and emacs running with the config above (and my regular color theme): as you can see, hard to distinguish from an X session.

Also, i definitely needed to interact seamlessly with the X clipboard, as you'd do in X11 Emacs:

(use-package xclip
  :ensure t)

(unless (display-graphic-p) (xclip-mode 1))

As mentioned, i delegate image display to feh and firefox in the few cases i need it, and interplay with zathura to handle PDFs and my associated notes, but that's stuff for a future post¹. With that in place, i'm finding myself pretty comfortable living in terminal Emacs most of my time.

Speedy hacking!

If you can read Spanish, i wouldn't miss the opportunity to read this beautfiul essay in the original: Irene Vallejo's prose is clear, elegant and very beautiful. It's a delight (and a relief) to read. And, if you can't read Spanish but have a translation handy, i wouldn't miss the opportunity to read it either, for a very entertaining account of the history of ancient books sprinkled with lots of interesting (to me, at least!) bits about the Greek and Roman worlds. The book is morever wrapped in a subdued and sober optimism that i've found reinvigorating and sorely needed in these times, when one often feels like running on empty. Heartily recommended!

I just got a second-hand copy of this classic. Sometimes, used books are more charming than new ones:

For many years i've used postfix to those ends; it has an acceptably simply-ish configuration; but recently i've become fond of VPNs (mullvad, if you want to know), and was annoyed by its getting confused when /etc/resolv.conf changes (for instance, because you get the VPN up after postfix's service has started). I've found a pleasantly simple alternative: OpenSMTPD.

Say i want to use the SMTP server fencepost.gnu.org when sending an email as jao@gnu.org and smtp.jao.io when writing with mail@jao.io or news@xmobar.org in my From header. OpenSMTPD let's you do that with a very simple configuration file in /etc/smtpd.conf¹:

table aliases file:/etc/aliases
table secrets db:/etc/mail/secrets.db

table sendergnu { jao@gnu.org }
table senderjao { mail@jao.io, news@xmobar.org }

listen on localhost

action "local" mbox alias <aliases>
action "relaygnu" relay host smtp+tls://gnu@fencepost.gnu.org:587 auth <secrets>
action "relayjao" relay host smtps://jao@smtp.jao.io:465 auth <secrets>

match for local action "local"
match for any from mail-from <sendergnu> action "relaygnu"
match for any from mail-from <senderjao> action "relaygan"

where we have also configured local delivery for a good measure. That's the full configuration file! The only other thing needed is generating the secrets.db file with the users and passwords corresponding to the keys gnu and jao (those are just arbitrary names). To that end, we create a plain text file with them, using entries of the form <key> <user>:<password>:

gnu  jao:my fencepost password
jao  mail@jao.io:xxxxxxxxxxxxxxxxx

where my user for fencepost.gnu.org is jao and for smtp.jao.io is mail@jao.io (you see there's no need of escaping spaces or ats). Then we use the program makemap to create the secrets db:

makemap secrets && rm secrets

notmuch comes with a tree-view (for searches of kind tree in notmuch's lingo) where you see your messages in a split window, with the upper half showing a forest of trees, similar to what you'd see in Gnus summary buffer (and many other clients, i suppose). Similar but not quite the same. In notmuch, all threads are always expanded, while Gnus has a nice mode in which all but the current one are folded. I really wanted that in notmuch.

Well, emacs to the rescue. Folding and unfolding sections of a buffer is the bread and butter of many emacs packages (i'm sure you've heard of org mode), and one of the simpler and more robust of them is outline-mode. So how about we activate outline-minor-mode in notmuch-tree-mode buffers, with an appropriate regular expression definition making the first message of each thread a header of the buffer? Is there a common pattern in that first message that we can use? Well, not quite: since the format of the message lines is customizable by the user, it's difficult to come up with a pattern that is not brittle. Unless we insert in the buffer, invisibly, our own section marker:

(defun jao-notmuch-tree--msg-prefix (msg)
  (insert (propertize (if (plist-get msg :first) "> " "  ") 'display "")))

and advice the notmuch function inserting messages (notmuch-tree-insert-msg) to call us:

(advice-add 'notmuch-tree-insert-msg :before #'jao-notmuch-tree--msg-prefix)

With that, we've put an invisible "> " prefix on message lines that are the first in a thread (notmuch handily marks them with :first in the message metadata passed to notmuch-tree-insert-msg).

Now all we need is to tell outline mode to use a regular expression that recognises the marker above:

(defun jao-notmuch-tree--mode-setup ()
  (setq-local outline-regexp "^> \\|^En")
  (outline-minor-mode t))
(add-hook 'notmuch-tree-mode-hook #'jao-notmuch-tree--mode-setup)

And that's (almost) it! We have now at our disposal all outline commands in the tree view, with thread folding that is even more powerful than Gnus's. For starters, we can use outline-cycle: i have it in TAB:

(define-key notmuch-tree-mode-map (kbd "TAB") #'outline-cycle)
(define-key notmuch-tree-mode-map (kbd "M-TAB") #'outline-cycle-buffer)

and let's define a command that shows only the current thread and folds the others:

(defun jao-notmuch-tree-hide-others (&optional and-show)
  (interactive)
  (outline-hide-body)
  (outline-show-entry)
  (when and-show (notmuch-tree-show-message nil)))

We can bind it to a convenient key, or perhaps just define a keymap with the most common outline commands and let my user bind it to the prefix they prefer:

(defvar jao-notmuch-tree-prefix-map
  (let ((m (make-keymap "Thread operations")))
    (define-key m (kbd "TAB") #'outline-cycle)
    (define-key m (kbd "t") #'outline-toggle-children)
    (define-key m (kbd "s") #'outline-show-entry)
    (define-key m (kbd "S") #'outline-show-all)
    (define-key m (kbd "h") #'outline-hide-entry)
    (define-key m (kbd "H") #'outline-hide-body)
    (define-key m (kbd "o") #'jao-notmuch-tree-hide-others)
    (define-key m (kbd "n") #'outline-hide-other)
    m))

i like to have it at "T":

(define-key notmuch-tree-mode-map (kbd "T") jao-notmuch-tree-prefix-map)

There's still one gnusim i missed: i wanted to have a command that goes to the next (or previous) message (or thread) folding and unfolding threads if i went from one to another. That takes a little more work, but it's not too bad:

(defun jao-notmuch--looking-at-new-p ()
  (when-let (ts (notmuch-show-get-tags))
    (or (member "unread" ts) (member "new" ts))))

(defun jao-notmuch-tree--next (prev thread no-exit)
  (let ((line-move-ignore-invisible nil))
    (cond ((jao-notmuch--looking-at-new-p))
          (thread
           (when (notmuch-tree-next-thread prev)
             (unless (jao-notmuch--looking-at-new-p)
               (notmuch-tree-matching-message prev (not no-exit)))))
          ((notmuch-tree-get-message-id)
           (notmuch-tree-matching-message prev (not no-exit)))))
  (when (notmuch-tree-get-message-id)
    (jao-notmuch-tree-hide-others t)))

(defun jao-notmuch-tree-next (thread &optional no-exit)
  "Next message or thread in forest, taking care of thread visibility."
  (interactive "P")
  (jao-notmuch-tree--next nil thread no-exit))

(defun jao-notmuch-tree-previous (thread)
  "Previous message or thread in forest, taking care of thread visibility.."
  (interactive "P")
  (jao-notmuch-tree--next t thread t))

I just bind the two new commands to n and p in notmuch-tree-mode-map. The final icing on the cake is having the tree view start folded. Since notmuch doesn't provide a proper hook informing you when it's been fully populated, we have to recur again to a little advice, this time for the function that is called when the notmuch process filling the buffer is done, namely notmuch-tree-process-sentinel:

(defun jao-notmuch--tree-sentinel (proc &rest _)
  (when (eq (process-status proc) 'exit) (jao-notmuch-tree-hide-others)))

(advice-add 'notmuch-tree-process-sentinel :after #'jao-notmuch--tree-sentinel))

And we're done. As mentioned, i find it very remarkable how little code is needed to get such a robust feature, thanks to the plethora of libraries already available in the elisp environment and the flexibility of the means at your disposal to combine them.

You can find the current status of this hack as part of my little jao-notmuch personal package for notmuch extensions.

Happy folding!

It had been a while since i last had this much fun with a programming languages book, and learnt so much in the process. It sure helped that i am a complete neophyte on the subject matter of dependent types: i had recently started playing with Idris, but reading this book really clarified the basics for me. I still remember how, after The little schemer kindled my love for parenthesis, The seasoned schemer made me finally grasp the meaning of continuations. I've got the feeling that the typer has done again the trick, this time giving me the jump start i needed on Curry-Howard, programs as proofs and the beauty of dependent types. As with continuations back in the day, i had read a lot about those things, and thought i had understood them, only to realise that i had not really.

The authors, Daniel P. Friedman and David Thrane Christiansen, have also created a language, Pie, and implemented it in Racket and in Haskell. I've used the latter in a couple of ways: first, it's a very fun learning experience as a weak haskeller (or as a fading racketeer, for that matter) to go over the code (make sure to check Checking Dependent Types with Normalization by Evaluation: A Tutorial, by David himself, if you're interested in how these things are implemented). And, second, the Haskell-based REPL has been my constant companion while reading the book, thanks to a little package that i put together to use it in Emacs, complete with syntax highlighting and a bit of completion for the predefined forms of Pie (it might have a couple of rough corners, but the plan is to submit it to MELPA at some point).

Or you can also use the DrRacket interface if that's your thing, but, be it as it may, don't miss this book!

I've been using leafnode since i was young to avoid network latency issues when Gnus fetches news from remote usenet servers. Leafnode is a store & forward NNTP proxy that can be used to give a regular newsreader off-line functionality. It works by fetching in the background news articles from a number of configured remote servers (gmane.io in our case), storing them locally and offering a local NNTP server to Gnus (or any other newsreader, for that matter). That way, one configures Gnus to fetch news from localhost, which is fast and will never block, even when one is disconnected from the interwebs. Leafnode's server implements the full protocol, so one can also post to the remote servers.

For our case, leafnode's configuration file is very simple:

## Unread articles will be deleted after this many days
expire = 365

## This is the NNTP server leafnode fetches its news from.
## You need read and post access to it. Mandatory.
server = news.gmane.io

## Fetch only a few articles when we subscribe a new newsgroup. The
## default is to fetch all articles.
initialfetch = 100

With leafnode in place, i've rarely needed to subscribe to a mailing list¹, and all their messages are available with the Gnus interface that we all know and love.

With one caveat: one can search over e-mails, using either IMAP (i like dovecot's lucene indexes) or (even better) notmuch. Can we do the same with those messages we access through leafnode? Well, it turns out that, using notmuch, you can!

First of all, leafnode stores its articles in a format recognised by notmuch's indexer. In my debian installation, the live in the directory /var/spool/news/gmane. On the other hand, my notmuch configuration points to ~/var/mail as the parent directory where my mailboxes are to be found. I just created a symlink in the latter to the former and voila, notmuch is indexing all the messages retrieved by leafnode and i can search over them!²

With the version of Gnus in current emacs master, it's even better. I can tell Gnus that the search engine for the news server is notmuch:

(setq gnus-select-method
      '(nntp "localhost"
             (gnus-search-engine gnus-search-notmuch
                                 (remove-prefix "/home/jao/var/mail/"))))

and perform searches directly in Gnus using the notmuch indexes. Or, if you prefer, you can use directly notmuch.el to find and read those usenet articles: they look just like good old email³ :)

;;; desktop.el --- save partial status of Emacs when killed -*- lexical-binding: t -*-

;; Copyright (C) 1993-1995, 1997, 2000-2021 Free Software Foundation,
;; Inc.

;; Author: Morten Welinder <terra@diku.dk>
;; Keywords: convenience
;; Favorite-brand-of-beer: None, I hate beer.

;; This file is part of GNU Emacs.

Mine is Guinness :)

During this year, i've contributed several little features to the package, and it's always been an easy and natural process. The last instance has been prompted by Sacha Chua asking me whether an emacs-specifc RSS feed was available, in order to add this blog to Planet Emacslife.

Turns out it wasn't available: org-static-blog did know how to use tags, but didn't generate per-tag RSS feeds. Until yesterday. It was a question of half an hour and a little PR to add that functionality. If you check the changeset, you'll see that most of its 62 additions and 24 deletions are just a bit of refactoring that make adding the feature almost trivial.

It was just another example of something i experience almost everyday in this Emacs life, namely, how easy and direct it is to mold the computer environment to fulfil new requirements, sometimes in idiosyncratic ways no external package is going to implement for you, and some other times (as in this case) in ways you can share with the community. The result is an environment almost exquisitely adapted to your needs, and it think that it is precisely this rooting in direct, day-to-day user needs that, at the same time, makes individual hacks so rich and useful to everyone else. That, and the fact that adapting an external package to your liking is so often just a couple lines of elisp away.

I hope i did it right, and you all Emacslife followers can see me waving hello, and this big thank you, Sacha! :)

(defun jao-consult--diff-lines (&optional backward)
  (let ((candidates)
        (width (length (number-to-string
                        (line-number-at-pos (point-max)
                                            consult-line-numbers-widen)))))
    (save-excursion
      (while (ignore-errors (diff-hl-next-hunk backward))
        (let* ((str (buffer-substring (line-beginning-position)
                                      (line-end-position)))
               (no (line-number-at-pos (point)))
               (no (consult--line-number-prefix (point-marker) no width)))
          (push (concat no str) candidates))))
    (if backward candidates (nreverse candidates))))

(defun jao-consult-hunks ()
  "Search for modified hunks in the current buffer."
  (interactive)
  (let ((candidates (append (jao-consult--diff-lines)
                            (jao-consult--diff-lines t))))
    (unless candidates (error "No changes!"))
    (consult--jump (consult--read candidates
                                  :prompt "Go to hunk: "
                                  :category 'consult--encode-location
                                  :require-match t
                                  :lookup #'consult--line-match
                                  :state (consult--jump-state)))))

(global-set-key (kbd "C-x v c") #'jao-consult-hunks)

i am sure i've taken one or two detours there that can be coded better using consult's API, but it was so nice to be able to have a working command in fifteen minutes that i couldn't resist showing off :)

• smartscan, a simple way of navigating programming modes

  (use-package smartscan
    :ensure t
    :commands smartscan-mode
    :init (add-hook 'prog-mode-hook #'smartscan-mode)
    :diminish)
  

• git-link, because i almost never look at files using the browser, but some people don't have my repos checked out. Specially nice the bit about being able to use git config variables.

  (use-package git-link
    :ensure t
    :custom ((git-link-default-remote "bigml")))
  

• visible-mode, an Emacs built-in, especially useful in org buffers, where i hide markup and sometimes it's a chore to ascertain whether point is before or after a it. With a binding to this minor mode, it's a breeze to toggle them:

  (use-package visible-mode
    :bind (("s-v" . visible-mode)))
  

Tip of the hat to Daniel Mai, for a couple of the above. You might find some other interesting tidbits in his config.

First, you'll remember that we were defining a function to detect a video URL:

(defun jao-video-finder ()
  "Check whether we're looking at a video URL.
Return (video-url . <URL>) if so."
  (when-let ((url (thing-at-point-url-at-point)))
    (when (string-match-p jao-video-url-rx url)
      (cons 'video-url url))))

Once we've got a non-null url value, even if it's not a video URL, it's still certainly a URL, and embark has a url category, so we could save a new parsing by the default URL finder by saying:

(when-let ((url (thing-at-point-url-at-point)))
  (cons (if (string-match-p jao-video-url-rx url) 'video-url 'url) url))

This has the potential drawback that we're overriding embark's finder, embark-target-url-at-point, and we might prefer to keep the latter.

Turns out that we can do that thanks to embark's target transformers. One can add to embark-transformers-alist an arbitrary function to be applied to a target of any given category, and embark will apply its actions to the transformed value. Omar calls this process, very aptly, a refinement of the target; here's how we would do it:

(defun jao-refine-url-type (url)
  "Refine type of URL in case it is a video."
  (cons (if (string-match-p jao-video-url-rx url) 'video-url 'url) url))

(add-to-list 'embark-transformer-alist '(url . jao-refine-url-type))

With this strategy, we don't need jao-video-finder at all, and it also makes lots of sense, conceptually, to have our video-url defined as a refinement rather than a new target¹. Omar's second suggestion is also in line with this concept: surely we want all actions available for url also for our video-url, don't we? Well, that's exactly the reason why the embark-define-keymap macro we used to define our actions can inherit all the actions already defined in another keymap, using the :parent keyword²:

(embark-define-keymap jao-video-url-map
  "Actions on URLs pointing to remote video streams."
  :parent embark-url-map
  ("p" jao-play-video-url))

(add-to-list 'embark-keymap-alist '(video-url . jao-video-url-map))

It is worth noting that this ability to inherit a keymap is not really an embark add-on: vanilla Emacs keymaps already have it, via the standard function set-keymap-parent. You could actually define jao-video-url-map without using embark-define-keymap at all, and it'd work exactly the same.

So, our code has become shorter and more featureful: thanks, Omar!

(when-let ((url (or (w3m-anchor) (thing-at-point-url-at-point))))
  (cons (if (string-match-p jao-video-url-rx url) 'video-url 'url) url))

(defun jao-w3m-url-finder ()
  (when-let ((url (w3m-anchor)))
    (cons 'url url)))

(add-to-list 'embark-target-finders #'jao-w3m-url-finder)

So i'm definitely testing the waters for it to become my default site for (newish) published code: here's my jao/elibs: Emacs libraries and little utilities repository for starters (and, if you look closely, you'll find also my emacs config nearby). If and when that happens, they're going to to get my humble contribution too, i reckon.