Kristoffer Balintona — #Tips and Tricks

Keeping a tidy .emacs.d/ with no-littering.el

Mon, 21 Apr 2025 00:34:00 GMT

No-littering.el keeps your .emacs.d clean. I’ve been using it for years—in fact it’s one of the only third-party packages I first installed several years ago when I started using Emacs that I still have in my config today.

It establishes conventions for keeping files created from packages:

The no-littering-etc-directory. The directory where packages place their configuration files.
The no-littering-var-directory. The directory where packages place their persistent data files.

If every package followed this convention, then no files should litter (pun intended) your emacs configuration directory. Unfortunately, not every package does… fortunately, no-littering already sets the relevant option of dozens of packages to use these directories. But if you use a package that isn’t already set, you can easily use no-littering-expand-var-file-name and no-littering-expand-etc-file-name to change that. For example: (setopt cursory-latest-state-file (no-littering-expand-var-file-name "cursory/cursory-latest-state")) sets cursory-latest-state-file to ~/.emacs.d/var/cursory/cursory-latest-state.

Here’s a look at my own directories.

My no-littering-etc-directory, located at ~/.emacs.d/etc/:

$ tree -L 1
.
├── abbrev.el
├── custom.el
├── gnus
└── transient

3 directories, 2 files

My no-littering-var-directory, located at ~/.emacs.d/var/:

$ tree -L 1
.
├── abbrev-mode
├── amx-save.el
├── anaconda-mode
├── annotations.el
├── auto-save
├── backup
├── bookmark-default.el
├── citre
├── company
├── cursory
├── dap
├── dape-adapters
├── desktop
├── devdocs
├── diary
├── eaf
├── eafpdf
├── eglot-java
├── elfeed
├── emacs-gc-stats.eld.gz
├── emms
├── emojify
├── erc
├── eshell
├── eww
├── flycheck
├── fontaine
├── fontaine-latest-state.eld
├── forge
├── gamegrid-user-score
├── gdb-bp-session
├── .gitignore
├── .gitmodules
├── gnus
├── helm
├── ielm-history.eld
├── image-dired
├── irony
├── ispell
├── keyfreq.el
├── languagetool
├── ledger
├── logview-cache
├── lsp
├── mc-list.el
├── multisession
├── newsticker
├── nov-save-place.el
├── nsm-settings.el
├── org
├── org-remark
├── persist
├── popweb
├── prescient-save.el
├── projectile
├── project-list.el
├── project-x
├── psession
├── racket-mode
├── recentf-save.el
├── request
├── savehist.el
├── save-place.el
├── semantic
├── shadow
├── speed-type
├── spell-fu
├── srecode-map.el
├── svg-lib
├── tempel-templates
├── tramp
├── transient
├── trash
├── treemacs
├── treesit
├── tree-sitter
├── type-break.el
├── undohist
├── url
├── vimish-fold
└── wombag

60 directories, 22 files

Without no-littering, I would either (i) have a ton of directories in my .emacs.d or (ii) have to define my own variables whose values are directories and manually, whenever I install a new package, set their options to write their files into these directories—basically what no-littering already does but without no-littering’s existing integrations. This way, my Emacs directory is neater.

Bonus: `(no-littering-theme-backups)` §

No-littering also provides the little-known no-littering-theme-backups. The TL;DR is this: this function makes Emacs’s built-in auto-saving and backing up functions create files within no-littering’s directories so that sensitive data is not written to disk in unsecured locations. Calling this function sets the value of three variables:

auto-save-file-name-transforms: Transforms to apply to buffer file name before making auto-save file name.
backup-directory-alist: Similar to auto-save-file-name-transforms but for backup files.
undo-tree-history-directory-alist (from undo-tree): Similar to auto-save-file-name-transforms but for backup files.

Its docstring elaborates the mechanism and purpose of this function in greater depth:

no-littering-theme-backups is an autoloaded native-comp-function in
no-littering.el.

(no-littering-theme-backups)

Theme locations where backups of various sorts are created.

The purpose of this package is to store data files of various
sorts in a handful of central locations, instead of spreading
them all over the place.  When doing that for temporary files,
which contain backups of some sort, that increases the odds that
sensitive data is written to disk in clear text and/or that such
clear text files persist longer, if they would be created anyway.

Because of that, simply loading ‘no-littering’ does not theme
certain, potentially unsafe variables.  Instead, this function is
provided, so that you can decide whether to take the risk or not.

Calling this function sets these variables:
- auto-save-file-name-transforms (built-in)
- backup-directory-alist (built-in)
- undo-tree-history-directory-alist (from ‘undo-tree’)

The default values of these variables cause additional files to
be created in the same directories as the files that are being
visited.  Calling this function changes the values of these
variables, so that this is only done for visited files located in
certain directories.  For all other visited files, the additional
files are created in files inside no-littering-var-directory.

Additional files are created in the same directory as the visited
file, for files located in:
- "/tmp/"
- "/dev/shm"
- temporary-file-directory

With these settings it is still possible that sensitive data is
written to additional files, but you are more likely to spot it,
and because these directories usually use a ‘tmpfs’ file-system,
the leaked secrets should not persist after a reboot.

If you do *not* call this function, then these additional files
are always created in the same directory as the visited files,
regardless of the location of the visited files.  In other words,
even when using the default values, there is a significant risk
of leaking sensitive data, and if you want to reduce that, then
you must turn of these features completely.

Complement corfu, vertico, and completion-preview with prescient.el sorting

Sat, 05 Apr 2025 14:23:00 GMT

Apr 7, 2025 With several commits made on April 6, 2025, vertico spun off its sorting functionality into an extension: vertico-sort. As explained in vertico-sort.el’s commentary section, it includes a new feature: when history-delete-duplicates is nil, all sorting functions defined in vertico-sort.el now rank recently selected candidates above frequently selected candidates. This approximates the sorting strategy of prescient.el. I think I’ll stick with prescient.el sorting because I like history-delete-duplicates set to non-nil, but try it out yourself!

Apr 22, 2025 Corfu now offers a similar functionality as vertic-sort does for vertico with the new corfu-sort extension. Like vertico-sort, corfu-sort requires history-delete-duplicates to be nil.

Prescient.el is a package that was popular during the era of ivy and helm. Nowadays, I don’t see it mentioned much because of the very popular corfu + vertico + marginalia + orderless combination which enhance built-in Emacs completion and overtaken ivy and helm in terms of popularity. (And it’s deserved! I use this combination, too.)^[1] But I’ve found prescient.el a noticeable convenience that complements this set of packages.

The reason is prescient.el’s sorting. Roughly, we can think of completion as having two halves: filtering and sorting. Filtering is what completion-styles does: among the generated completion candidates, which are shown to the user? Sorting is the order in which the filtered candidates are shown. One might think that orderless, which is filters candidates with its completion-style, also sorts candidates—but it doesn’t. As explained in the orderless README:

The prescient.el library also provides matching of space-separated components in any order. It offers a completion-style that can be used with Emacs’ default completion UI, Mct, Vertico or with Icomplete. Furthermore Ivy is supported. The components can be matched literally, as regexps, as initialisms or in the flex style (called “fuzzy” in prescient). Prescient does not offer the same flexibility as Orderless with its style dispatchers. However in addition to matching, Prescient supports sorting of candidates, while Orderless leaves that up to the candidate source and the completion UI.

As such, in the corfu + vertico + marginalia + orderless world, vertico (for minibuffer completions) and corfu (for in-inline completions) are responsible for sorting candidates.

The problem is this: although orderless brilliantly narrows down candidates, both vertico and corfu have somewhat naive sorting algorithms (see vertico-sort-function and corfu-sort-function). Vertico offers vertico-sort-history-alpha and vertico-sort-history-length-alpha, and corfu offers corfu-history-mode. In my limited experience, however, I give prescient.el’s sorting algorithm an edge to both. (YMMV—feel free to try them!) Oftentimes vertico and corfu will consistently show the candidate you have in mind later in the list. This tends to be the case when using certain common commands and certain completion-at-point-functions: I would common seek out certain candidates that orderless would place third or fourth in the list.

Prescient.el almost entirely solved this issue for me. Prescient.el offers a completion-style—this is its filtering functionality—but it also offers sorting functionality. The sorting functionality is what’s relevant here:

When sorting, the last few candidates you selected are displayed first, followed by the most frequently selected ones, and then the remaining candidates are sorted by length.

Prescient.el is the core package, and there are several auxiliary packages to integrate prescient with vertico, corfu, and others. We can enable prescient’s sorting for vertico and corfu (but not its filtering; I want to leave this to orderless) with something like the following:

;; Core package
(use-package prescient
  :custom
  ;; My settings for relevant user options:
  ;; (prescient-aggressive-file-save t)
  ;; (prescient-sort-length-enable nil)
  ;; (prescient-sort-full-matches-first t)
  ;; (prescient-history-length 200)
  ;; (prescient-frequency-decay 0.997)
  ;; (prescient-frequency-threshold 0.05)
  :config
  ;; Optional: persist prescient statistics to an on-disk cache
  ;; (`prescient-save-file')
  (prescient-persist-mode 1))

;; Integration with corfu
(use-package corfu-prescient
  ;; The :after keyword defers loading this package, meaning this package is
  ;; only loaded until something else wants something from it.  If we want
  ;; `corfu-prescient-mode' to be enabled in the :config block, we need to
  ;; prevent deferral with the :demand keyword. In combination with our :after
  ;; block, the package is immediately loaded only after both corfu and
  ;; prescient are loaded.
  :demand t
  :after corfu prescient
  :custom
  ;; Sorting.  These are the default values but I include them here to be
  ;; explicit.
  (corfu-prescient-enable-sorting t)
  (corfu-prescient-override-sorting nil) ; Don't override `display-sort-function'

  ;; Filtering
  (corfu-prescient-enable-filtering nil) ; We want orderless to do the filtering
  ;; See also `corfu-prescient-completion-styles',
  ;; `corfu-prescient-completion-category-overrides' and
  ;; `prescient--completion-recommended-overrides'.  Those options apply only
  ;; when `corfu-prescient-enable-filtering' is non-nil.
  :config
  (corfu-prescient-mode 1))

;; Integration with vertico
(use-package vertico-prescient
  ;; The :after keyword defers loading this package, meaning this package is
  ;; only loaded until something else wants something from it.  If we want
  ;; `vertico-prescient-mode' to be enabled in the :config block, we need to
  ;; prevent deferral with the :demand keyword. In combination with our :after
  ;; block, the package is immediately loaded only after both vertico and
  ;; prescient are loaded.
  :demand t
  :after vertico prescient
  :custom
  ;; Sorting.  These are the default values but I include them here to be
  ;; explicit.
  (vertico-prescient-enable-sorting t)
  (vertico-prescient-override-sorting nil) ; Don't override `display-sort-function'

  ;; Filtering
  (vertico-prescient-enable-filtering nil) ; We want orderless to do the filtering
  ;; See also `vertico-prescient-completion-styles',
  ;; `vertico-prescient-completion-category-overrides', and
  ;; `prescient--completion-recommended-overrides'.  Those options apply only
  ;; when when `vertico-prescient-enable-filtering' is non-nil.
  :config
  (vertico-prescient-mode 1))

The result is using orderless for completion filtering and prescient for completion sorting everywhere—for in-line completions with corfu and minibuffer completions with vertico. With this, among the candidates filtered by orderless, the most recent and common ones will be bumped up to the beginning. Try it out!

Bonus: integration with `completion-preview-mode` §

Emacs 30.1 ships with the new completion-preview-mode. You can read about it in this blog post but also in the Emacs 30.1 news (i.e., C-u 30 C-h n). Apparently, completion-preview-mode has its own sorting function—which makes sense, since it isn’t hooked into either corfu nor vertico (which we set up to use prescient above). The relevant user option to modify its sorting is completion-preview-sort-function. So we just have to make sure that function matches prescient’s. We can do that like this:

(with-eval-after-load 'prescient
  ;; Have `completion-preview-mode' use prescient's sorting algorithm
  (setopt completion-preview-sort-function #'prescient-completion-sort))

But, if you also use corfu on top of completion-preview-mode, you’ll still notice a discrepancy between corfu’s first candidate and completion-preview’s candidate. They should be the same with the same sorting algorithm but they’re not! I’m not 100%, but I’m fairly confident that corfu-prescient keeps track of corfu-specific completion usage, which is separate from non-corfu-specific use. Consequently, the statistics used to sort candidates ends up different between corfu and prescient-completion-sort.

In any case, below is a simple fix that gets corfu and completion-preview on the same page:

;; We set completion-preview's sorting function
;; (`completion-preview-sort-function') to corfu's sorting function
;; (`corfu-sort-function').
(with-eval-after-load 'corfu
  (setopt completion-preview-sort-function corfu-sort-function))

;; Alternative: for a solution that ensures `completion-preview-sort-function'
;; always matches `corfu-sort-function', we can use a variable watcher.  This is
;; my preference.
;;
;; The below accounts for cases in which (i) the user has buffer-local values
;; for `corfu-sort-function' or (ii) the user changes the global value of
;; `corfu-sort-function' (e.g., from minor modes that disable/enable
;; functionality).  It is a robust solution, and although I have not tested its
;; performance overhead, it should cause no problems.
(add-variable-watcher 'corfu-sort-function
                      (lambda (_symbol newval operation where)
                        "Match the value of `completion-preview-sort-function' to `corfu-sort-function'.
If `corfu-sort-function' is set buffer-locally, also set
`completion-preview-sort-function' buffer-locally.  Otherwise, change
the default value of `completion-preview-sort-function' accordingly.

This action only applies when the value of `corfu-sort-function' is
set (i.e., OPERATION is \\='set).  This excludes, e.g., let bindings."
                        (when (equal operation 'set)
                          (if where
                              (with-current-buffer where
                                (setq-local completion-preview-sort-function newval))
                            (setopt completion-preview-sort-function newval)))))

Changelog §

Apr 7, 2025
- Fixed several typos.
- Added clarity to several phrases.
- Added a note mentioning the new vertico-sort extension.
Apr 5, 2025
- Correction to explanation according to r/JDRiverRun’s comment.
Apr 22, 2025
- Added a note mentioning the new corfu-history extension.

Jujutsu (jj) VCS workflows and the convenience of its “operation log”

Thu, 27 Mar 2025 08:35:00 GMT

Over the last month or two I’ve been trying out the relatively new jujutsu version control system (VCS) — and loving it. At first, I discovered it and read their GitHub README with curiosity but skepticism. Then I sought a few YouTube videos^[1] demonstrating jj in action, and a tutorial for a text-based reference. I became very interested. I initialized a jj repo in one of my small git projects and played around. Since then, I’ve migrated all of my personal repositories to jj, and use jj for practically everything.

From the time I’ve spent with jj, I’ve felt myself sliding into some general workflows:

A jj squash workflow
In git, this would be a workflow where you make a commit and continually amend/extend that commit until its intended goal is completed.
1. Make progress toward a desired goal.
2. Commit (jj commit, or jj new then jj describe -m "...") with a message describing this unit of work.
3. Continue making changes.
4. Squash (perhaps interactively: jj squash -i^[2]) new changes until the desired goal is accomplished.
5. Maybe change the description of the previous commit commit.
Work in the working copy
1. Envision a goal for a new commit. Express that into the description of the working copy commit: jj describe -m "...".
2. Work until much of that goal is met.
3. jj new to work on the next goal. Or jj split -i if some of the changes in the working copy belong in the next commit.
4. jj edit to hop between commits and work on each until completion. Perhaps jj new -A ... one or more times when when you don’t want certain changes in a commit: make changes across however many of those commits, then jj squash them all into your original commit when you’re happy. (You’re basically creating a new git branch!)
Concurrent commits workflow
Work on several commits simultaneously, using combinations of jj squash, jj new, and jj rebase to make make reversible changes while having a clean jj log at the end. In essence, this is point (3.4) above but with room for added complexity.

I’m not a VCS expert, and my projects are small, but I’ve gravitated to (1) and (2) without feeling any mental strain of keeping track of where this and that change is and what CLI operations avoid x problem or y merging conflict (which, by the way, jj permits! Jujutsu treats conflicts as first-class, so conflicts and their resolutions percolate through ancestors and descendants without problem.)^[3]

Perhaps the most exciting part of using jj is fearlessly making changes and experimenting. This has been an extraordinary boon for my learning about how to use jj in accordance to its VCS concepts. The reason is jj’s operation log (jj op log) and the ability to revert back to any past repository state (jj op restore OPERATION_ID).

With jj op restore, I can merge branches, create conflicts, resolve conflicts, mess up… then go back as if it never happened. I can make sweeping repository changes without fear! In git, I’d be walking on egg shells, worried about the potential to ruin the entire state of my local repository if I’m not careful…

I’d definitely recommend trying jj out if you haven’t already! Easily turn a git repo into a jj repo with a git backend: jj git init \-\-colocate.

A surprising upside to vc-dir marks over magit

Wed, 27 Nov 2024 04:40:00 GMT

Vc.el is Emacs’s built-in interface for version control CLI tools. With respect to Git, magit has for several years now been the most favored (with respect to popularity) Git^[1] interface. At least in the r/emacs subreddit, magit is frequently considered a killer-feature—an irreplaceable feature unique to Emacs.

For the most part I am inclined to agree. However, in the last few months, I’ve been regularly experimenting using vc. This is in part motivated by recent improvements to vc’s implementation of Git, and another part motivated by a curiosity to see whether I’d end up enjoying some parts of the vc-way of doing things over the magit-way of doing things.^[2]

On such insight has been the surprising benefits of calling vc-dir instead of magit-status.

The nicety of `vc-dir` marks §

In magit-status, I would typically stage various files and hunks and commit them when ready. vc does not use Git’s “staging” concept (because not all version control systems use such a concept). So instead, to achieve something analogous, a user might call vc-dir (or, much more commonly for me, project-vc-dir), mark edited files (or entire directories!) using vc-dir-mark (m), and check out (commit) those changes via vc-next-action (v) or see a diff of those changes with vc-diff (=) and commit the changes in that diff-mode buffer (v).^[3]

A problem for the magit interface, however, is visual clarity when it comes to focusing on changes in a certain subset of files. For example, sometimes I am working with changes in files within a single directory alongside many other uncommitted changes elsewhere in the repository. To make a commit with magit, I would need to navigate past or fold changed hunks/files I want to ignore. With many unstaged changes this means many files to ignore. This leads to a significant reduction in visual clarity since I end up having to ignore more files than I’m currently working on.

There is a subtle solution in vc.el. The secret lies in the fact that marks, which can be used to selectively create diff buffers and commit changes from those buffers, are preserved in vc-dir buffers after changes are committed. A mark is only removed once the corresponding line is removed via something like vc-dir-hide-up-to-date (x) or vc-dir-kill-line (C-k). Marks are magical because they let me focus on the files relevant to my current work: I can mark the files and directories I am focusing on then call vc-next-action in the vc-dir buffer to commit changes only in those files and directories (or, if I want to be selective about the hunks I commit: first call vc-diff to see the diff of just the marked files, kill/remove the hunks I don’t want to commit, then vc-next-action).Then I can write more changes and make more commits in the same way. (Furthermore, while this vc workflow might seem like it would necessarily involve many more keystrokes, I found this not to be the case under certain scenarios.)

In short, with vc.el, a really efficient workflow is

vc-diff or vc-root-diff → vc-next-action and
vc-dir (with persistent marks) → vc-diff → vc-next-action.

The latter is unique to vc.el, and a feature I don’t think the magit UI can replicate. So while magit can sometimes become visually cluttered, vc-dir marks let users focus on their current work by easily excluding from view files and directories one is not concerned with currently.

A caveat §

Historically, I’ve found this especially fruitful when working on my literate Emacs config^[4] (wherein any “single change” involves changes to the .org file as well as the resulting tangled file(s)) and Emacs packages. Still, I think I prefer magit in cases where the staging functionality of Git is crucial. For instance, I have a repository that houses all my org notes and org-agenda files. There are frequently many changes for this repository, so the convenience of staging/unstaging has been crucial for me. In cases like these, I haven’t found an equivalent for vc.el yet.

Changelog §

Mar 25, 2025
- Add clarifying prose to paragraph.
- Change formatting of “vc.el” and “magit.”

Neat behavior of M-x occur

Sat, 09 Nov 2024 06:00:00 GMT

Having used Emacs for several years now, I somehow hadn’t come across the prefix argument and active region behavior for one of the most well-known commands: occur.

Below is the docstring of occur reads, with the relevant portions preserved:

occur is an interactive native-comp-function in replace.el.

It is bound to M-s o.

(occur REGEXP &optional NLINES REGION)

Inferred type: (function (t &optional t t) t)

Show all lines in the current buffer containing a match for REGEXP.
If a match spreads across multiple lines, all those lines are shown.

[…]

Each line is displayed with NLINES lines before and after, or -NLINES
before if NLINES is negative.
NLINES defaults to list-matching-lines-default-context-lines.
Interactively it is the prefix arg.

Optional arg REGION, if non-nil, mean restrict search to the
specified region. Otherwise search the entire buffer.*
*REGION must be a list of (START . END) positions as returned by
region-bounds.

[…]

When NLINES is a string or when the function is called
interactively with prefix argument without a number (C-u alone
as prefix) the matching strings are collected into the ‘*Occur*’
buffer by using NLINES as a replacement regexp. NLINES may
contain \& and \N which convention follows replace-match.
For example, providing “defun\s +$\S +$” for REGEXP and
“\1” for NLINES collects all the function names in a lisp
program. When there is no parenthesized subexpressions in REGEXP
the entire match is collected. In any case the searched buffer
is not modified.

[…]

So:

When called on a region, on that region is searched.
When called with a numerical prefix argument, that many lines before and after every match is added to the search results. (This reminds me of next-screen-context-lines.) This functionality is particularly useful to me since added context is sometimes necessary.^[1]
When called with a universal argument, just the matching string (not the entire line) is inserted into a line in a read-only buffer.
If called from elisp and NLINES is provided (as a regexp string), then the behavior is like C-u but matches can be modified like replace-match. (See (elisp) Replacing Match for more information.)

Also, searching “NLINES” with apropos-documentation brings up a few other built-in commands that have similar functionality. isearch-occur, multi-occur, list-matching-lines, and occur-context-lines to name a few.

Pretty neat!

Kristoffer Balintona — #Tips and Tricks

Keeping a tidy .emacs.d/ with no-littering.el

Bonus: (no-littering-theme-backups) §

Complement corfu, vertico, and completion-preview with prescient.el sorting

Bonus: integration with completion-preview-mode §

Changelog §

Jujutsu (jj) VCS workflows and the convenience of its “operation log”

A surprising upside to vc-dir marks over magit

The nicety of vc-dir marks §

A caveat §

Changelog §

Neat behavior of M-x occur

Further Reading §

Bonus: `(no-littering-theme-backups)` §

Bonus: integration with `completion-preview-mode` §

The nicety of `vc-dir` marks §