Emacs tweaks: Choosing what to hack on

Posted: - Modified: | emacs, life, productivity

[2024-01-22 Mon]: How do you combat being overwhelmed by choice? is somewhat relevant. I particularly like this comment which talks about delaying the decision to see if it still makes sense.

Is it the Emacs lifecycle that you tweak your config for few months and then you live off of fat of the land for >4 years? My Emacs config is a Org-tangle spaghetti that I touch only if I want to set some more sane config variable.

@xgqt@emacs.ch

This got me thinking about how tweaking my config fits in with other things I want to do–how I choose what to hack on and for how long.

Text from sketch

Choosing what to hack on - 2024-01-16-01

When it comes to computer work, I can usually choose what to do.

Idea -> Test

XKCD on automation: time to automate vs frequency x time saved

I focus more on what I'll enjoy (both the destination and the journey)

  1. How can I make this better?
  2. What's the smallest step I can take? What can I fit in 15-30 minutes?
  3. What's nearby?
    • Relevant functions or packages
    • Next steps, possibilities
  4. What kinds of notes can I leave for myself or others?
  5. like desire paths: where, what size
  6. or like a river wearing down rocks

Sometimes when I chat with other people about automation, this XKCD chart about Is It Worth the Time? comes up.

I realized that this isn't quite how I consider things. I'm lucky in that when it comes to computer things, I get to choose most of the things I spend my time on. My consulting clients have very long wishlists that I pick from based on interests and priority, and I play with Emacs for fun.

Drawing of a task sandwich with Emacs tweaking, the actual task, and blog posts and comments

Because I enjoy tinkering around with Emacs, I often build a little Emacs hacking into my tasks. 15 or 20 minutes of exploring an idea can make it even more fun to do the actual task it's supposed to help with because then I want to test it out. Then after the task is done, I get to write about it. It's like making a little task sandwich with really nice bread. This is also a little related to sharpening the saw, which is pretty fun in Emacs. (Vim people do it too!)

These little changes add up over time, making things even more enjoyable. It's a little like the way desire paths show where people actually walk between buildings and give a sense of how much they are used, or how rivers smooth down the edges of stones. The easier I make something, the more likely I am to do it, and the more I'll get to enjoy the results of my code. It's a little like the Igors described in this essay.

When I think about something I might tweak about my Emacs configuration, I usually consider the following:

1. How can I make this better?

I like looking for ways to reduce manual work or looking-up. I tend to have a hard time with tedious, repetitive tasks. I also keep an eye out for things I've been meaning to learn.

2. What's the smallest step I can take? What can I fit in 15-30 minutes?

Small steps make it easy to squeeze in things here and there. I know my brain's going to suggest half a dozen things along the way, so it helps to start as small as possible and capture most of the other things in my inbox for later. That way, I can get to experience the benefits right away without feeling lost.

Another advantage of picking really small tasks and using Org Mode to capture the rest of the ideas is that I can try to avoid the Ovsiankina effect.1 I spend most of my day taking care of our 7-year-old, so I squeeze in my focused-time tasks early in the morning before she wakes up. Sometimes I have little opportunities to work on things throughout the day, like when she wants to read a book or watch a video. She might do that for 15-30 minutes before wanting to connect again. If I pick the wrong-sized task or I don't dump enough rough notes into my inbox so that I can get the open loops out of my head and trust that I can pick things up again, the unfinished part pulls on my brain and makes it harder to enjoy time with her. Then I get tempted to let her binge-watch Minecraft or Rubik's cube videos2 so that I can finish a thought, which doesn't quite feel like good parenting.

Lastly, I don't usually understand enough about my needs to build something complex from the start. Trying things out helps me discover more about what's possible and what I want.

3. What's nearby?

Thanks to Emacs's amazing community, there are usually relevant functions or packages that I can borrow code from. I mostly have a sense of things from the blog posts and forum threads that cross my radar because of Emacs News, and I should probably get used to skimming the descriptions in the "New packages" list because that can help me find even more things.

When coming up with possible approaches, I also sometimes think about other related ideas I've had before. Filing those ideas into the appropriate subtrees in my Org files sometimes helps me come across them again. If I can take a small step that also gets me closer to one of those ideas, that's handy.

I also like to think about next steps and possibilities. For example, even if I spend an hour or two learning more about data visualization with Org Mode and plotting, that's something I can use for other things someday. This works pretty well with keeping things small, too, since small parts can be combined in surprisingly interesting ways.

Let me try to trace through a web of related features so I can give you a sense of how this all works in teeny tiny steps.

G defun defun my-include:...?from-regexp=...&to-regexp... my-include:...?from-regexp=...&to-regexp... defun->my-include:...?from-regexp=...&to-regexp... my details my details defun->my details defvar defvar defun->defvar emacsconf-el emacsconf-el defun->emacsconf-el context context defun->context my-include:...?name= my-include:...?name= my-include:...?from-regexp=...&to-regexp...->my-include:...?name= :summary :summary my details->:summary defun-open defun-open :summary->defun-open web links web links emacsconf-el->web links Embark Embark :comments both :comments both Embark->:comments both QR code QR code Embark->QR code :comments both->context web links->Embark

  • defun: I often wanted to write about a specific function, so I wrote some code to find the function definition and copy it into my export post hidden inside a details tag with the first line of the docstring as the summary. 2023-01-02
  • my-include:...?from-regexp=...&to-regexp...: Sometimes I wanted to write about longer pieces of code. I wanted to include code without repeating myself. The regular #+INCLUDE can handle line numbers or headings, but neither of them worked for the Elisp files I referred to since the line numbers kept changing as I edited the code above it and it wasn't an Org Mode file. I made my own custom link so I could specify a start and end regexp. 2023-01-08
  • my_details: I wanted to put the code in a details element so that it could be collapsible. I made an org-special-blocks template for it. special-blocks
  • :summary: For Org source blocks, I wanted to be able to do that kind of collapsible block by just adding a :summary attribute. 2023-01-27
  • defun-open: I wanted to sometimes be able to keep the function definition expanded. 2023-09-12
  • emacsconf-el: Since I was writing about a lot of EmacsConf functions in preparation for my presentation, I wanted a quick way to link to the files in the web-based repository. 2023-09-12
  • defvar: Made sense to include variable definitions too.
  • web links: The emacsconf-el links were so useful, I wanted to be able to use that type of link for other projects as well. 2024-01-07
  • Embark: I wanted to be able to copy the final URL from a custom link at point, so I used Embark. 2024-01
  • QR code: I started livestreaming again, so I wanted a quick way for viewers to get the URL of something without waiting for stream notes. 2024-01-10
  • :comments both: While scanning Reddit to find links for Emacs News, I learned about :comments both and how that includes references to the Babel file that tangled the code. 2024-01-07
  • context: Now that it was easy to link to the web version of an Emacs Lisp file, I thought it might be fun to be able to automatically include a context link by passing link=1. I also wanted to be able to navigate to the Org source code for a tangled function. 2024-01-11
  • my-include:...?name=...: I wanted to be able to refer to Org Babel source blocks by name.
I promise it's all connected. (Pepe Silva meme)

In the course of writing this blog post, I learned how to use URLs in Graphviz, learned how to include inline HTML for export with @@html:...@@, used position: sticky, figured out how to highlight the SVG using JS, used CSS to make a note that should only show up in RSS feeds, and submitted a pull request for meme.el that was merged. And now I want to figure out sidenotes or at least footnotes that don't assume they're the only footnotes on the page… This is just how my brain likes to do things. (Oooh, shiny!)

4. What kinds of notes can I leave for myself or others?

I might take years before revisiting the same topic, so good notes can pay off a lot. Also, when I share what I've been working on, sometimes people e-mail me or comment suggesting other things that are nearby, which is a lot of fun. The ideas I come up with are probably too weird to exactly line up with other people's interests, but who knows, maybe they're close enough to what other people work on that they can save people time or spark more ideas.

Inspired by Mats Lidell's EmacsConf 2023 talk on writing test cases, I've been working on writing occasional tests, too, especially when I'm writing a small, function to calculate or format something. That's a good way of sketching out how I want a function to behave so that I can see examples of it when I revisit the code. Tests also mean that if I change things, I don't have to worry too much about breaking important behaviours.

Ideas for next steps

How can I get even better at this?

  • Popping the stack (untangling interruptions and ideas): When I let myself get distracted by a cool sub-idea, I sometimes have a hard time backing up. I can get back into the habit of clocking time and practise using my org-capture template for interrupting task so that I can use C-u with C-c j (my binding for org-clock-goto) to jump to a recently-clocked task.
  • Braindumps can help me use non-computer time to flesh out notes for things I'm working on or ideas for next steps.
  • If I skim the descriptions of new packages in Emacs News (maybe even the READMEs instead of just the one-liners), I'll probably retain a brief sense of what's out there and what things are called.
  • Vector search across package descriptions and function docstrings could be an even more powerful way to discover things that are close to something I want to do.
  • Using elisp-demos to add more examples to functions can help me look up things I frequently use but don't remember.
  • Figuring out more modern IDE features like refactoring support, on-the-fly error checking, and code navigation could help me code faster.

So that's how I tinker with Emacs for fun: start with something that mostly works, keep an eye out for opportunities to make things better, use tinkering as a way to make doing things more fun, look for things that are nearby, and

Footnotes:

1

I used to think this was the Zeigarnik effect, but it turns out the Zeigarnik effect is about remembering incomplete tasks versus completed tasks, while the Ovsiankina effect is more about intrusive thoughts and wanting to get back to that incomplete task.

2

At the moment, she likes Eyecraftmc and J Perm.

View org source for this post
You can comment with Disqus or you can e-mail me at sacha@sachachua.com.