Planet Emacslife

Just a quickie from Marcin Borkowski (mbork) today. Like many of us, mbork likes to turn on global-auto-revert so that any file open in Emacs that gets changed by an external process has the changes reflected in the Emacs buffer.

Sometimes, though, you don’t want that to happen. Mbork gives the example of viewing a PDF file while LaTeX is updating it. The question is: how to prevent auto revert from updating certain modes.

That turns out to be pretty easy. As usual, Emacs has us covered. The global-auto-revert-ignore-modes variable lists all the modes that should be ignored by auto revert. You can check mbork’s post for the details but it’s really quite simple: you list the modes that auto revert should ignore and that’s it.

This is, really, a niche concern but if you have it, mbork’s post tells you how to avoid it.

#emacs #brainiac #productivity #systems

Time has come to release a new version of Brainiac. The whole configuration file has been almost completly restructured, cleaned up and properly commented. So I will declare this to be version 2.0.

Following changes have been made:

• READ.md has been extended to explain the installation and usage.
• Readability improvements:
  • All colors decisions are now left to Modus themes, we only change typografy, e.g. underline the PROG tasks to encode work in progress.
  • Multiple Org elements were restyled, e.g. ellipsis, tags etc., to improve scanability in large documents.
  • Added the configuration for fixed and variable pitch fonts. You may set the font family to your liking.
  • Packages org-bullets, org-appear and diminish introduced.
  • Priority cookies are removed after the task is closed, to remove visual clutter.
  • When saving, the tags will be aligned automatically.
• Added number of matches to isearch.
• Repeaters are now visible in the agenda.
• When jumping to items from the agenda, automatic narrow is done to improve focus.
• Capture from anywhere is now implemented by a custom script based on org-protocol.
• Many, many small tweaks, fixes and changes.

Get the new release from here.

Enjoy and keep hacking!

In this livestream, I chatted with Prot about the May 2026 Emacs Carnival theme "May I recommend". It was a joint braindump of quick recommendations for people at different points in their Emacs journey, building on our conversation about newbies/starter kits and the newcomer experience all the way up to power users, Emacs Lisp coders, and package developers.

View in the Internet Archive, watch or comment on YouTube, read the transcript online, download the transcript as a PDF or VTT, or e-mail me.

You can add the iCal for upcoming Yay Emacs episodes to your calendar. https://sachachua.com/topic/live/upcoming-livestreams.ics

Find more Yay Emacs posts or join the fun: https://sachachua.com/topic/live

Transcript

Expand this to read the transcript

0:00 Opening

Sacha: My typing is still going to be very loud, but that's okay.

Prot: That's part of the charm.

Sacha: Okay. All right. Here we go. Let's go live. Hello, everyone. This is Yay Emacs [32]. I forgot which number. Anyhow, I'm here with Prot because it's Emacs Carnival for May 2026, and the theme is "May I Recommend" because I like puns and couldn't pass up the chance to say "May." So "May I recommend..." is our topic, and our goal for this one is to brain dump a whole bunch of things that people might find useful in their Emacs learning journey. We've already talked about newbies and starter kits in the previous two conversations we've had in Sacha and Prot Talk Emacs. This time, we're going to focus more on users who are getting started with... They've decided this is going to be their everyday tool. They want to learn more about keyboard shortcuts and finding their way around, building the habits, finding their preferred resources. Power users, maybe, who are starting to look at different packages, these are maybe the people who are saying, okay, maybe let's try this package for working with Org Mode in addition to the basic stuff, or let's try doing email in Emacs. Customizers, who are beginning to get into Emacs Lisp to write functions. This is where you start to customize it a lot more to your tastes and your workflows. Contributors and people who are actually sharing their source code, maybe even turning it into packages, participating mailing lists and discussions. So this whole range of people all working on different skills at different levels. What I think we're going to do with this is we're just going to braindump a whole bunch of recommendations. You're welcome to ask questions, and I'll ask you questions as well. We'll just untangle everything and organize everything afterwards.

Prot: That's great.

Sacha: There we go. In this list of skills that people can develop, are you thinking of other skills that aren't on this list yet that do make a big difference to how people use and learn Emacs?

Prot: I need to enlarge my screen a little bit. I think what you have there is good.

2:27 Tip: Less is more. Start small.

Prot: What I had in mind also is more of a meta-point, or more general thing, like an approach style, which is "less is more," if I were to condense it. Start small. Make sure you make it work when it's small. Extend it from there. Don't start big and try to simplify it, because that doesn't work.

Sacha: I grouped that idea under managing time, notes, and attention and also breaking things down, because the overwhelming nature of things is something a lot of people struggle with, both Emacs and elsewhere. Even just that meta-skill of saying, "okay, this is a small chunk that I'm going to focus on because I know that's what my brain can handle" versus "let's architect this entire thing" and you're six hours down the line and you're nowhere near the thing that you want it to do.

Prot: And of course Emacs invites you for that because it's like, here are like a hundred powerful tools for you to combine in ways that nobody else has thought of before, right? So it's like asking you to do that, but it's a trap. You don't want to go down that route. Or at least don't go there too early.

Sacha: Managing the rabbit hole. Yes, there are going to be a lot of temptations and some of those temptations are quite legitimate. Yeah, you do have to figure this part out in order to get this other thing that you wanted working. But sometimes it's just a trap.

Prot: Yeah.

Sacha: Okay, so that's managing. Okay, what other meta-skills here should we talk about as a framework so that when we dive into the specifics, we know we're covering a lot of the ground people need?

4:07 Tip: Start with what is built in

Prot: Not so much a meta skill, but consistent with this line of reasoning is as a good heuristic, start with what is built in and extend from there, because usually what is built in will give you a baseline of functionality. So it works with a "less is more" approach.

4:27 Skill: Figuring out the words to look for

Sacha: I feel that sometimes figuring out the words to look for, finding out what it might be called in Emacs source or in the built-in packages... That's something that's hard to develop unless you're reading manuals and reading other people's posts because the terminology can be quite arcane.

Prot: Oh yeah, for sure.

Sacha: Getting a sense of what might be built in and what it might be called and where to look for it, I think, is definitely a skill.

Prot: Yeah, for sure. One good way to think of this is, what do I want to do? In the most simple form, if you forget about Emacs, for example, for a second, and you're like, okay, what am I trying to do? I'm trying to write a blog, or I'm trying to deal with email correspondence, or I'm trying to manage my TODOs. In its most simplest form, how can I solve this problem? That can already help you formulate the questions.

Sacha: Formulating the questions is actually really hard, in the sense that sometimes people don't even notice that there's a question that they can ask, and they don't know what kinds of solutions might address that problem actually. They get distracted by A, but actually it's B that will solve the problem. Considering the different kinds of solutions that can address the same problem, developing a sense of which ways are easier to do the Emacs way versus harder to do. Why make something really complicated when a built-in package or whatever can solve that problem in a more elegant way? All of these things require the development of intuition.

Prot: Yes, yes, and with some experience, of course, that helps, for sure. But then it's the other, which you can also consider as a meta skill.

6:25 Tip: Be okay with starting over

Prot: I believe there was also a point of this, be okay with declaring bankruptcy in Emacs. Bankruptcy, I think... the essence of that is not really much bankruptcy, but be okay with trying something, which is an experiment, and then learning something from it, distilling the essence of that, and then trying something else. I think a sense of experimentation will help you build that skill of, okay, now I can intuitively figure out what works and what doesn't work.

Sacha: I think that's a really interesting point because sometimes you get very attached to "there's this thing that I've started to build" and then you start bolting more and more things onto it, when really, sometimes the prototype is your way of understanding the problem. Then when you take it all out and you say, okay, now that I understand a little bit more, what can I make? How do I change my workflow with that new understanding? Sometimes it's as extensive as declaring Emacs bankruptcy and starting again from scratch. Sometimes it's just, maybe, the approach that I'm taking is not a fruitful one. I should go try something else.

Prot: Yeah, exactly. You can only have that feedback loop if you try, so trial and error is the way to go.

Sacha: @gcentauri has a question or a comment about discoverability, figuring out how to navigate Emacs in order to discover things. Where would we put that in this skill? This is figuring out the words as well, right? Isn't it?

Prot: Yeah, by the way, I'm in the chat here.

Sacha: Where did you read that?

Prot: Okay, okay, I see it here. It was off my screen. Okay, I see it now.

8:16 Skill: Learning to discover

Prot: And of course Christian... I'm reading the temperatures in Western Europe. They are terrible. Yes, I know.

Sacha: Yeah, big heat wave. So, figuring out discoverability. Learning how to navigate Emacs. Because Emacs is lovely. It's self-documented, everything at your fingertips, but you've got to know how to get those fingers on them.

8:42 Tip: Read manuals for fun

Prot: Yeah, the manual helps. It will present some of that. But of course, you have to read the manual. So you are in a situation where you have to have the skill of reading the manuals in order to discover, but to discover... So yeah, it's a tricky thing. You have to know where the manuals are.

Sacha: Yeah, and you have to be unintimidated by them, I think. I got into it easy because I've always been used to reading books above my level. Even as a kid, I was reading my sister's data structures and algorithms books. I didn't understand anything the first time around. But after nine times through, you start to understand some of the concepts and how they go together. And the more you read something, the more of those concepts start to make sense to you. You read it, you read other things around it or related to it, and then the jargon becomes less impenetrable. You begin to understand it. So one of my recommendations is I recommend reading the Emacs manual, the Org manual, all these book-shaped things for fun. Even if you don't think you're going to immediately use 90% of the things, every time you read it, you're going to learn something.

Prot: Yeah. Plus, of course, you will know you are an Emacs user if you are reading manuals for fun.

Sacha: How else are you going to find out about Org spreadsheets and whatnot, right? It's just too big to fit in your brain.

Prot: Correct. Yeah, that's really good. You could even make it a habit of, okay, this day I will read one chapter from the manual.

10:16 Tip: Use Emacs bookmarks to save your place in the manual

Prot: Actually, to say something on this, if you learn about the bookmark mechanism of Emacs, you can bookmark info manuals. So if you are reading the manual from inside of Emacs, you can use the bookmark facility to be like, last point in the Emacs manual. You could have a bookmark that is a rolling bookmark, right? So you could be updating it whenever you go to the next chapter. This way, little by little, you can read the manual.

10:43 Tip: Generally, investing time into navigation and note-taking workflows pays off

Sacha: In general, figuring out your navigation and note-taking workflows so that they're super convenient for you, whether that's Denote or Org Mode Capture or whatever else that you're using... As you read, taking notes on the things that you find interesting in a way that makes it easy to jump back to more information is definitely worth the upfront investment of learning.

Prot: Yeah, 100%.

Sacha: Okay, @gcentauri confirms. They are actually a true blue Emacs geek, was reading the manual right before bed and came across the forms library. Yeah. No idea it existed. Yeah. So: read stuff, make it easier for you to jump back to the place that you left off or the parts that you found interesting. That's a great recommendation.

Prot: Just to add another metaskill related to this. Don't read it before going to bed because if you discover something useful, you are not going to sleep.

Sacha: I think the idea there is get really good at telling your brain, yes, that's really cool, but if you stay up until 1, you are going to regret it. So just add a TODO and let it go.

Prot: Exactly.

Sacha: This may have happened to me a number of times.

Prot: Yeah, yeah, same. So, only read the manual in the morning or when you wake up.

Sacha: Are there other metaskills that are not yet captured in this or do we start digging into each of these skills?

Prot: I say we dig in and if we think of something we can always add it later.

Sacha: All right. What strikes your attention here? Which of these things?

Prot: No, no. You can go wherever. I don't mind. Anything will do well.

12:19 Skill: Keyboard macros

Sacha: There's a whole lot of stuff here in the customizer, packager thing around modifying or gluing together code that is not something easy for people to pick up because they're just not used to it in other programming languages or platforms or whatever. Things like: you could use keyboard macros to cobble together a quick workflow. You don't even have to write a big function. Just developing the intuition that, oh, this is a set of repeatable functions or repeatable commands is one thing,

12:53 Skill: Modifying the behavior of code via hooks and advice

Sacha: all the way to "this is how I use hooks and advice to either modify the behavior of something where the person who coded it has anticipated that a hook will be needed here, or advice in case they didn't plan for it at all." You're just going to override things yourself. How do people develop this sense of what's possible and how to do things?

13:15 Tip: Learn to think in terms of buffers and windows

Prot: Yeah, it's a difficult skill but it's something you develop by experience. The point to remember is that in Emacs, at its core, you have buffers and everything is a buffer and buffers are displayed in windows If you think in terms of that abstraction, something like a keyboard macro becomes a tool that will jump between buffers, will switch windows. It has no problem doing any of that. You are not limited in your thought to, okay, I have to work exactly where I am right now. I think that's a general approach that goes very far with what you do. Of course, when you are thinking of the advice and the hook, that I think is a little bit more advanced because you need to also have the skills to write advice. With hooks, maybe not. But for advice, you will need to understand exactly what is happening.

14:07 Skill: Reading the source code; Tip: Just jump in

Sacha: I have definitely jumped ahead here because this also requires the skill of reading people's code in order to find out there is a hook or there is some advice that you can do, or there's a variable and this is how you can let bind it to temporarily change its value during this part of the code. Let's talk about reading source. What sorts of things help people develop that skill of reading the source code?

Prot: You have to just jump in at some point. Like, you might do it by accident when you are in a help buffer and either you misclick S, which goes to the source, or you follow the link from above. But anyway, the point is it's a good skill to just, a good habit rather, just jump in and try to read it even if you don't know any programming. Try to read it as if it's English and try to see what you can understand. And of course, some functions will be extremely difficult. Others will be more straightforward. So I think eventually by exposure through osmosis, as it were, you will already learn something.

Sacha: I love the fact that our functions in variable names are often very long and it makes sense in English because we're not trying to squeeze into some very concise, very terse convention. Just put a full sentence in there. It's fine. We just use completion anyway. It's all good.

15:33 Tip: edebug is great for exploring code

Sacha: One of the tips that I'll put in here because people sometimes miss it is the power of Edebug. If people haven't come across Edebug yet, it's great because you can interactively step through what the code is actually doing and you can evaluate what the value is of this variable at this point. And every so often I had to go into the Edebug menu bar and remind myself, okay, you can set conditional breakpoints and all these other things that I have to remember that exist and can be used. But Edebug, if you're going to learn Emacs Lisp, learn Edebug.

Prot: Edebug is really powerful for sure and it's especially useful when you have functions that are relatively long. I mean what they are doing like they have a lot of steps and you have to understand the flow. Like if it's a very short function maybe you don't benefit all that much from eDebug but in practice you will need it. It's very powerful.

16:26 Tip: Reading tests can help you understand code, too.

Sacha: And the other thing I want to point out is that sometimes packages have tests and reading the tests can give you even more of an idea of how this function is supposed to behave. It's not always the case, but when there are tests, they're great.

Prot: In an ideal world, we will update our tests.

Sacha: Alright, so that's reading source code. There's so much that's really interesting to read. Sometimes you come across interesting idioms for Emacs Lisp and you're like, oh yeah, that's a great way to iterate through all the buffers and match a certain thing, whatever.

17:02 Skill: Idiomatic Elisp

Sacha: And so if you're in this customizer phase of things and you want to move to the contributor level, learning idiomatic Elisp is definitely like, okay, it makes things a lot easier.

17:17 Tip: Write tests.

Sacha: Charlie says, Edebug and ERT tests change the way I develop Elisp. No longer flying blind. Great. Yeah, great. In particular, I tend to break things whenever I make changes. So it's really nice to be able to say, okay, I'm going to nail down this behavior, at least for now. With a little bit of thinking, sometimes you can write tests for things that you would do interactively. So you can test a whole lot more because you have buffers and windows than you might in other languages.

Prot: Yeah, correct, correct. And you get to see it live.

17:52 Tip: When writing Emacs Lisp that expects a list, use plurals

Prot: Just to say on this point of when you are going through the tests and through everything, one basic thing which is in idiomatic Emacs Lisp is when you are writing the parameters of a function, if you are expecting a list, you use plural. For example, you have a function that goes through buffers. Your parameter is just called buffers. And that alone should tell you that it's a list of stuff. You don't say, for example, list of buffers, right? That's superfluous. You just say buffers, this automatically means it's a list. So that's very common. You will see this a lot.

Sacha: Here I am. I've been calling my variables buffer-list. Sometimes figuring out what I should call a function or call an argument is a bit challenging, but I figure I'll just name it whatever comes to mind and then I can defalias it or do a search and replace afterwards.

18:59 Tip: When naming, be verbose rather than terse

Prot: Yeah, but when in doubt, of course, be verbose rather than terse.

Sacha: Oh, yes. And when you find yourself still using the wrong words to try to find it again, just add more aliases and you'll find it eventually.

Prot: More verbose. More words. All the words.

Sacha: All the words. All the words. All right. What are the things here do we want to dig into? Adopting is always an interesting challenge and it's a challenge at all levels here, right? It's like from the user trying to figure out, okay, how do I remember to use this keyboard shortcut or whatever to, all right, I've written this new function. It's great, but I have to remember to use it. Do you have any recommendations around changing the workflow?

19:46 Tip: Iterate on your workflow in small steps

Prot: In accordance with what I said in the beginning, iteratively. Try to memorize one. You have this new function that, let's say, streamlines how you list files in a directory, whatever, I don't know. right and use it don't have all 10 functions and try to remember them just use one after two weeks use the next one after four weeks use the third one and so on, and little by little, make it something that you just do automatically you don't think about and with the recognition that you want to remember them all

20:20 Tip: Make things more automatic, and use context-sensitive clues

Sacha: And in fact, going on that point of automaticity, I also like making sure this stuff happens without me having to think about it. So if there's a hook that I can take advantage of to just have it automatically turned on, or if there's a context menu I can add it to so that I know, okay, if I do this, then I'll see it in a shorter list and I can get to it more easily instead of having to remember how to find it and all these details. Just all these little ways to make it easier for myself to automatically enjoy the improvements or at least have a chance of finding it again.

Prot: Yeah, yeah. And this is in the spirit of prefix keys with the help of the which key package, for example, or what Embark is doing. So it's in that spirit. Of course, there are different approaches. Maybe you want to set up a transient and in the given mode that you just type question mark, for example, and it breaks up your transient with what you want to do. Like there are very strategies you can go about to do something like that. I lost your audio, just to say. Yeah, no problem. Let's see. Of course I can sing in the meantime, but I don't think the audience will like it. Let's see. Let's see. Yeah, no problem. No stress. Of course we could do this. Don't forget that there was a time in history where cinema thrived with technology like this. So it will work. Okay, I can read a little bit from the chat. So something I love doing is after I've learned that one function at the late

Sacha: Can you hear me now? No. Test. Okay, okay, okay. Woohoo! Successful panicking. Alright. Great. Great. Magic? Something is happening? I don't know what is happening. My video is less important. It's fine. You may continue. Oh yeah, for sure.

24:48 Skill: Thinking in terms of elements

Sacha: Even just thinking, okay, here are the elements that it can work on and here are the actions that I want to associate with those elements. I guess it starts with the intuition of what are the things that I can address. And what I do is I just look at the embark source code and I'm like, oh yeah, okay, Org headings, that makes sense, and variables and all that stuff. I always like looking at people's setups. Okay, this one says you are now too quiet. Can you say something? Okay, okay, this is definitely a me problem. Hang on a second. Oh, okay, okay, okay, I think... Ah, technology. Why is it so fun? Test. Test. No, this is not right. No, no, no.

Prot: Let me know if you can hear me now. And of course, in the meantime, I can comment on the weather. I don't know if I can be heard. But in Western Europe, the temperatures are record high. And here in the mountain of Cyprus, it's like 20 degrees Celsius max.

Sacha: Okay. So did you hear any of the stream? Is Prot's audio okay now? You've got to keep talking, I guess.

Prot: Yeah.

Sacha: Oh, my goodness.

Prot: It's completely different.

26:16 Skill: Reading other people's configuration and adapting ideas to yours

Prot: We can hear him loud and clear. Wonderful.

Sacha: Back to braindumping. Very good, very good. So we talked about Embark and other things and practices and workflows. I learned by reading other people's configurations, but it does take a fair bit of intuition in the first place to realize this part of the configuration means This, and how to adapt that into my own workflow. Is there a way for people to develop that aside from just reading tons and tons of configs?

Prot: At some point you just have to try. You just have to try and be like, okay, this package everybody raves about, they must be doing something good. I don't know what that is, so I have to try it and see for myself.

27:07 Tip: Start with focusing on just one thing

Prot: Then for something like Embark... We are just using it as an example, but I think it's a good example for other things. Something like Embark can do a million things, but you can also use it for just one thing, right? Find the one thing that you can use it for, use it for that, then figure out what is the second thing and take it from there. The same can be said for Org and all sorts of packages.

27:33 Blog posts and videos are useful

Sacha: I find that sometimes videos are useful for it in terms of seeing it in context, but on the other hand, sometimes I don't have the patience to watch a whole video. I particularly enjoy the posts that are both blog posts plus videos, so I can just skim the blog post, copy the code without having to pause and type things in manually, but also see how it works by somebody showing me how they use something.

Prot: Yes. That's the idea.

28:09 Tip: Take notes as you learn, and ideally, share them too.

Sacha: I do want to sneak in this recommendation to share. I keep beating this drum. But whenever I write about something that I've learned, I always end up getting these comments from people who point out other things that I should check out too. So I highly recommend, whether you're a beginner or whether you're a power user of Emacs, try blogging. I am happy to add people's blogs to Planet Emacs Life so people can read your stuff. All the notes are great for both crystallizing what you know as well as possibly inviting other people to share other tips and comments that point out that what you just worked on is actually a built-in package and all you have to do is configure this. Happens to me often.

28:54 Tip: Accept being a beginner.

Prot: And what can help with blogging, especially once you are blogging about something that you know has a very high skill level, is to approach it in a diary-like way, where it's like, today I learned about such and such. I am not an expert, I am learning, and this is fun. That's your blog post. You don't have to present yourself as the foremost expert on the matter, because then of course you will have to wait many years to write that blog post.

Sacha: I think that goes under this separate intuition thing for mindset and accepting the fact that no matter how many years of Emacs experience you have, you're going to be a beginner in 90% of the things that Emacs can do. So we can totally just accept the beginner's mind. There's no need to worry about imposter syndrome because we're all like this. We're all figuring things out. If you want, you can put in the disclaimer. You can say, "I'm totally a beginner. Read this for the idea and not the Emacs Lisp style" if you're embarrassed, you're self-conscious about sharing your code. But yeah, we're all just starting out, essentially. I like the fact that people in the community are so accessible. There's no one really saying, oh, I'm an expert. You should do it. You should do it this way and only this way, because we're all aware that again, we've done it this way, but there are probably five or six other implementations that could be even better that are really out there.

Prot: Yeah, exactly. Exactly.

Sacha: Charlie says that the leverage of blogging is unique in the Emacs community. Incredibly supportive, knowledgeable, and social group of people. That's another encouragement to go try it. And that is all good. In fact, there are a few days left in this May carnival for May I Recommends. If other people have recommendations, I'd love to hear about them too. Okay, so let's talk about... Actually, what do you want to talk about? What do you want to talk about?

Prot: Let's go and do something with the power users.

31:16 Group: Power users

Prot: With the power users, of course, you have a group that is, I would think, in some ways more diverse. Because of course there are different ways to become a power user. One, for example, is using Org more; another is using it as an IDE. So the common thread I would say here is that you are the kind of person who is digging deep. That's what you are as a power user. So if you want to become a power user, you have embedded as skills reading manuals and checking the source code, that sort of thing.

Sacha: At this point, you're like, "Emacs is going to be my tool. There's a lot of depth to it." And this is where you start reading, okay, "How do I use Org Mode?" Or "How do I set up my IDE so that it's just the way that I want it?"

32:13 Tip: Browse through package lists

Sacha: For fun, I will sometimes look through the package lists just to see what's out there that I can easily reuse. But often, it isn't even a matter of adding additional packages to your configuration.

32:25 Tip: Dive deeply into the packages you have: customization options, code, etc.

Sacha: It could just be diving deeply into the ones that you do already have, looking for options, looking for little things that you can toggle on and off, or considering how the different functions can be integrated into your workflow.

32:41 Tip: find-library gets you to the source code, occur can help you browse it

Prot: And to this end, I will add something that I do frequently because it combines the elements of what we have already covered, which is M-x find-library. You select the package you are interested in. You go there, then you do M-x occur. And you search for defcustom with a parenthesis in front. "(defcustom". This will produce an occur buffer with all the user options. So you do two things now. You learn about the user options, and you are looking at some source code. That's one way I can start reading source code.

Sacha: This goes back to why we don't just tell people... You don't like Customize, so the M-x customize + regular expression is off your list. Just look at the source code.

Prot: You'll be happier. Yeah, exactly.

33:29 Tip: You can also browse through Customize

Sacha: Browsing through Customize is also an option because it'll tell you about the things. You don't have to use the Customize interface to set it, but I have come across very interesting options that way, just clicking around.

Prot: Yeah, for sure.

Sacha: @gcentauri's like, yeah, I'm bored, M-x list-packages.

33:48 Tip: Have fun with randomness and serendipity

Sacha: Sometimes I randomize these things. I think for EmacsConf, either last year or the year before, we had random packages being displayed as a screensaver. I know people have sometimes on their dashboards, they'll display random inspirational quotes. It could be a random Emacs package. I think at one point I had it display random interactive functions, just so I could stumble across more commands. Taking advantage of serendipity can be a fun way to squeeze in a little bit of learning.

Prot: Nice, nice, yes. That's good.

Sacha: All right, so Jason Torres says, "I use custom just to explore."

34:32 Tip: Check out people's workflow descriptions and stories

Sacha: Another recommendation I'd like to put in here is reading other people's workflow descriptions. Again, going back to blogs and videos and all of that. It's because a lot of these things are not obvious from looking at the source code, but when somebody tells you a story about what problem they had and how they combined pieces of different packages to solve a problem, then it becomes a lot more real.

Prot: Yes. Plus, it puts you in the spirit of Emacs, which is you can be creative and piece together different elements of functionality and have a workflow that works for you.

Sacha: Let's try plugging in, re-plugging in my webcam. Let's see what happens.

Prot: Let's see, let's see. The moment of truth.

Sacha: Everyone will just have to imagine my eyebrows of agreement. Okay, so that's the power user. This is how you get even better at it.

35:42 Resources: manuals, Mastering Emacs, Emacs Lisp Elements

Sacha: I think Mastering Emacs would probably be like a book recommendation in this area. And for customizing Emacs and actually writing Emacs Lisp, there's your Emacs Lisp Elements book. What other things would you recommend aside from, yeah, read the intro to Emacs Lisp and the Emacs Lisp Memo for fun?

Prot: Of course, what you have listed there are all useful. The other one would be in the spirit of what we said earlier of trial and error. Learn how to, or rather get in the habit of writing little snippets of code. They don't have to be the best code of your life. Just something that gets the job done. Of course you can improve it later, but by getting in the flow of writing your own code, eventually what happens is you write better Emacs Lisp. You develop intuitions of what could go where, and eventually, before you know it, you are better at Emacs just because you were doing this little routine.

Sacha: Noticing the questions. This is also a skill. This is also something that you develop. A lot of times people do not even know what's possible because they're so used to just taking for granted that this is a limitation of the system. So sometimes we have to see somebody else, you know, fly through the code without worrying about like, okay, I have to go do this and do that and whatever. Oh, somebody says it's, ah, my Obie said, thank you. Asha has pointed out that OBS has my webcam, which is why the browser couldn't find it. So I will think with that some more, but in any case, we will continue.

37:29 Skill: Figuring out what's possible and making a habit of writing tiny functions

Sacha: Yes, so figuring out what is possible and then writing a tiny function for it and developing that habit of not tolerating these little bits of friction, I think is a skill. It's a thing you can develop.

37:45 Skill: Being mindful of what you do over and over again

Prot: Yeah, and another skill which is along the lines of writing your own code but maybe also a meta-skill is: be mindful of what you do over and over again. For example, let's imagine now you have a command that switches to the other window and then blinks the cursor or whatever, right? And these are two commands and you do them all the time. You do the one, you do the other, okay? Now you can write one command, which is a wrapper of those two, and all it does is call interactively the first, call interactively the second. Just by piecing those together you already have your own little command.

38:26 Tip: Keyboard macros can help you jumpstart custom functions

Sacha: Oh, I definitely want to point out here that you can use keyboard macros to generate the Emacs Lisp for it. So even if you're not that comfortable with Emacs Lisp, or you don't remember what the keyboard shortcuts do, you can record a keyboard macro. So you've definitely learned how to do that. And then you can get it to print out the Emacs Lisp that the set of keyboard actions ran. Or at least the Emacs Lisp to repeat the same keyboard shortcuts and then it will all figure it out. Anyway, so that's there. You can save that sequence of commands as a Lisp function in your config. So that's one thing, using keyboard macros to jumpstart your Emacs Lisp.

39:11 Tip: Use C-h k (describe-key) to describe shortcuts or menu items

Sacha: And the second thing is using C-h-K or Describe Key to see what a given keyboard shortcut or menu item will actually run. So that's all very useful stuff for figuring out the Emacs list to do something you're doing interactively.

Prot: I think that's the most used help command I do. C-h k. It's super useful all the time. It's very, very helpful. And not only you learn what command it calls, but also in which key map it is bound. So for example, C-c C-c in an Org buffer, it is telling you what the command is, and it is telling you this command is bound in the Org mode map. So if you want to change something, you know that you also have to be mindful of the key map. So there is your key map.

40:04 You can set up M-x to show keyboard shortcuts too (Marginalia?)

Sacha: Yes, it tells you other shortcuts. Oh, and along those lines, one of the M-x variants shows key bindings as well, which I recommend. If you're a power user, you'd like to become more of a power user, even a regular user, right? You want to start moving to using keyboard shortcuts for your more common commands and setting up your M-x command completion so that it hints at the keyboard shortcuts. Emacs by default also tells you about it after you run a command that had a shortcut. But at least that way, when you're looking through the command list you can see, "Oh yeah, this has a shortcut!" And then you can maybe even cancel out of your M-x and practice using that shortcut right away.

Prot: Exactly.

Sacha: And along those lines, I like using marginalia and consult because then I can see the command descriptions alongside the command name. So there's a little bit more detail there.

Prot: Yeah, I think you meant vertical. Vertical and marginalia.

Sacha: Oh, yes. It's one of those things, yes. It just works with everything. So yes, ready to go for completions that show you a lot of detail and then marginalia to actually show the thing on the side, which is helpful.

Prot: And of course, consult is wonderful as well, of course.

Sacha: Yes.

41:26 Resource: Emacs from Scratch series by System Crafters

Sacha: @ashraz would like to recommend the Emacs from Scratch series by System Crafters. They say it's a bit dated from 2020, but still mostly relevant in general. There are a lot of video resources out there.

Prot: Yeah, yeah, that's good. 2020, oh my goodness. It's been so long, I can't believe it.

41:50 Tip: Old tutorials can still be useful, although don't treat them as the sole source of truth (things may have changed since then)

Sacha: It's really interesting because I've been trying to organize the tutorial resources that people who are new to Emacs will come across. And a lot of times, some of the Org videos are from 10, 20 years ago. But they're still valid. So we have to make sure people don't immediately get turned off by the date in the video. But at the same time, they can start to tell the difference. Okay, this stuff is still applicable. But this stuff over here, it needs to be translated into how you do it in modern times. So it's a little challenging for people to navigate this.

Prot: Which of course points to another meta skill which is generally information related to Emacs is useful and it will work long into the future. But don't take a tutorial or a video as the source of truth. Always use it as a proxy. Okay, I get the idea. Now I will have to check the documentation and so on.

42:55 Skill: Finding preferred resources

Sacha: So I think that part of the learning journey as a user is also finding your preferred resources. Because a lot of times you're not going to learn everything the first time around. And everyone thinks in different ways. So you do need to spend some time looking for the kinds of resources that jive with the way that you think, with the task that you want to do or the workflow you want to have. And it's using the language at the right level for you, et cetera, et cetera. So even knowing, going in, that you're not going to find one-size-fits-all tutorial because Emacs has so many different workflow possibilities. Spending some time to figure out what you like as a tutorial or as a reference and then going back to that again and again as your understanding develops, I think is a thing worth doing.

Prot: Yes, yes, exactly. And of course, that's the whole point of Emacs more broadly: that it accommodates the different kinds of people because it's so customizable. So if something doesn't work for you, don't try to force yourself to work the way it is. Rather, change Emacs to work the way you think. And on a meta note,

Sacha: Finding people who think the kind of way you do is super helpful, like the tribe within the tribe. For example, you've got this cluster of people who like using the note because their brain works the same way that yours does when it comes to filing their notes.

44:37 Tip: If you find your tribe, look for ways to keep in touch with them

Sacha: Once you find that connection, finding ways to keep up with what those people are doing, and often this is RSS because that's a great way to get the updates without getting buried in email. That can be a great way to keep stumbling across things that might help you.

44:58 Tip: Manage unequal RSS frequencies with folders or tags

Prot: Yes, yes, that's a very good point. On the topic of RSS, just to say something that I learned many years ago the hard way: RSS works best if you subscribe to resources that don't post 30 or 50 or 100 articles a day. If you subscribe to the BBC or whatever, that will not work because it will crowd out the blog that posts once every month.

Sacha: What I do with that is I have different folders. Folders, filters, etc. Yeah, folders or tags or whatever. So all the microblogs or all the very prolific things go into one folder, which I generally ignore because it's hard to go through. Fair enough.

Prot: Subscribe.

Sacha: Yeah, the people who post once a day or once a week or once a month or once every blue moon, then it's easier to keep up with them because it's not buried in all of that stuff. You can look into your RSS readers to support for keywords maybe in order to do some more filtering and prioritization. This is one of the things that I've always envied about people who use Gnus for reading RSS. Because there's nnrss. Then you can use Gnus's scoring to prioritize the RSS items automatically for you. But that's definitely a power user thing, because it's Gnus.

Prot: I think that's a power user among power users. That's really an exception.

46:33 Tip: Doing more things in Emacs has compounding benefits

Sacha: Actually, that touches on an interesting thing about becoming more of a power user of Emacs in which if you let Emacs assimilate more of your life, if you start to use Emacs for more and more things, you get not just linear improvements but compounding ones as the things that you have can interact with other things. I'm thinking even just for the base case of if your to-do list is in Emacs and your coding is in Emacs, then you can create to-do items that link to your code, all the way to if your email is in Emacs, then you can make your to-do refer to your email and stuff like that.

Prot: Exactly. That's where it gets really powerful.

Sacha: If you want to get even deeper into the power of Emacs, try to push more of your life into it. I love seeing the things that people do with browsing the web in Emacs. What kinds of things do you do in Emacs that make you go like, this is where the power of having everything together works out really well.

Prot: You already mentioned them, like email in Emacs together with your agenda, but also Dired, because you can mark files and attach them to the message composition buffer. You can run a M-x shell and your three marked files in Dired, you type w or 0 w and you get their path and then you can do something with them from a shell, if you cannot do it directly from calling a shell command from Dired. There are many ways like that. The keyboard macros where you can jump, let's say, from a Dired buffer to a shell buffer or from one buffer to another. All these little things. For me, it's very powerful. You use it all the time.

48:31 Tip: Learn to think of it as just text

Prot: At some point, you don't even think about it. It's just text laid out in windows, each of which shows a buffer. So at some point, it doesn't matter if it's email or programming or prose. At some point, they are all the same. So it doesn't matter at all.

Sacha: Developing that mindset of "it's just text" and the facility for working with text, such as keyboard macros, or being able to jump around, or writing your own functions to manipulate it, or even just using isearch to go through it or using undo in different contexts. I think that's definitely something that people develop and when they develop that intuition, it really helps.

Prot: Yes, yes, exactly. In the beginning you won't think about those linkages. They won't be obvious to you. But just be mindful that they are there. They are possible. As you use Emacs, at some point you just feel naturally about them, and they happen. You're like, oh yeah, of course that was always possible. Of course, with the benefit of hindsight... In the beginning, you will be like, "Wow, I can do that!"

49:46 Tip: Take notes along the way

Sacha: That's the other reason why I want to encourage people to take notes along the way, ideally sharing them, of course, but even just for yourself, because a lot of times you will get to the point where this is just the way you've always done it. On the other hand, if you had those notes as you're figuring out how to do it, and you share those notes, then you're leaving these breadcrumbs for other people who are traveling down the same or similar path. That's something that would be very helpful for people.

Prot: Yeah, exactly.

50:16 Tip: Explore different ways to navigate and act on things

Prot: Even if you don't have external packages... For example, a workflow that for me was so powerful that I was like "Yeah, this is the way to go" involved the grep and then editing the grep results. But even if you don't use a bespoke package for that, which of course is also built into Emacs now, the functionality, you can use the grep results just as a way to jump to the result. If you hit RET, it takes you to the buffer at the point where the result is. You can have a keyboard macro that jumps to the result, makes some edit, goes back, jumps to the next result and repeat, right? You can do that even without the package. The point is that you can collect results and edit them in like a second or a minute, whereas you would need literal hours to do that and it would be error-prone.

51:09 Tip: Learn to combine different building blocks

Sacha: Yeah, and this points to the skill of being able to see and work with different building blocks. You have a block for, this is how to navigate. There are different ways to navigate. You could navigate to something based on some matching text, or you can navigate to something based on a line. You can set up your windows so that you can switch between windows or whatever. Then if you can combine that with, okay, these are some building blocks for acting on something, or this is how I can use the kill ring to take it to... or this is how I can use registers so that I can save some text or save a position or whatever else. The more of these building blocks that you can develop slowly, because being able to internalize the concept takes time, then all these different ways that you combine it to solve a problem makes Emacs very powerful.

Prot: Yeah, exactly. That's a good way to think of it, as building blocks.

Sacha: I don't know how people will do that either, aside from read the manual for fun and watch Emacs videos and read other people's posts. Often I think, what if we make a skill tree, right? Because people like gamification... But then this is going to be a really ridiculous, large skill tree with arrows going all over the place.

Prot: No, no, you don't want to do that. It will be the RPG that never ends. There is no final boss.

Sacha: @yogi583 asks what is a built-in function's name to edit grep result in Emacs?

Prot: I don't know but what I usually do is... Grep edit mode I think. It's new, right? It's new. It's built into Emacs 31 I believe.

52:47 Tip: Get the hang of keybinding conventions

Sacha: What I think of it is I go to the grep buffer and I press C-x C-q because that's the general "toggle read only"... That's another mental concept there, right? Getting a sense of the key binding conventions that might be translated into different actions in different places.

Prot: Yes. There is an annex to the Emacs Lisp manual, the Emacs Lisp reference manual, which talks about the key binding conventions, which is very useful for people to read. Even after you read that, it's a little bit hard to reason about the key bindings if you are getting started, but trust the process. You will see the patterns as you go. Generally, you can expect C-x to be global key bindings, and C-c followed by control something to be major-mode-specific key bindings.

Sacha: One of the things I like about reading other people's configs is that they'll rebind something and I'll be like, yeah, I can totally take advantage of that keybind because I'm not using the standard one as much.

Prot: Let me tell you about one I used. Of course, there are many, but by default, you close Emacs with C-x C-c.

Sacha: Who closes Emacs?

Prot: Yeah, people who make mistakes in life, such as myself. So because I would fat finger that the whole time, you want to unbind C-x C-c and then do C-x C-c C-c then you can exit. I would do it by mistake the whole time and I would destroy whatever I was working.

Sacha: Yeah, key binding design is this whole other thing that I haven't really mastered myself either. We've talked before about making the key bindings make sense. When they're mnemonic, they're easier for people to remember, right? But this is definitely something that I struggle with.

Prot: So think of it this way, of course assuming there is a space for it or you unbind something. C-x something is a global key potentially with a prefix, as a prefix. C-x r is a prefix, C-x p is a prefix and they have global scope, right? If you are doing something that is global in nature, it should work everywhere. You may want to do the same if you are okay with overriding default key bindings, right? Otherwise, you want to do something that is more specific. C-c C-something for a mode. Again, optionally overriding what a major mode is doing. Then you have to work with that. Use mnemonics. Use words that make sense. For example, C-s is the default key for searching. M-s is the prefix for alternative search. Think of it. Alt-S, right? All the alternative kind of searches, such as M-s o, right? So you can now think of M-s and then g would be my grep. M-s and f would be my find and so on. You can think in concepts like that.

56:06 Tip: Use which-key for keybinding help

Sacha: When in doubt, keep which-key enabled so then it will remind you at least of what else you've had configured for that prefix. That's the other recommendation. which-key mode, it's built in now. Just go use it.

Prot: Yeah, which-key mode is very useful. If you are using the Embark package, it has a key that will take over C-h. So actually that works even with default. If you type an incomplete key sequence, C-h will produce a listing with all the keys that complete that sequence. So it will be a help buffer that will tell you, okay, C-x, C-h, for example, will list everything that follows C-x. And it will name the command and all that. So that's also something to consider. I think if Embark were to add the which-key functionality where it's like C-h on a timer, I think then Embark would be a straight upgrade over which-key. In that regard. So Omar, if you are listening... Asking for a friend.

Sacha: @gcentauri says, "I recommend learning how to define a key map and put it under a leader key. I have M-m as my personal key map and then the things I find very useful I add to my key map." For this one, I've been experimenting with bind-key, which makes all of this stuff much easier in terms of defining prefix key and adding a docstring and all those other lovely things.

57:41 Tip: Figure out your ergonomics

Sacha: I like your other meta tip about experimenting with how your keyboard is set up. So for example, even on my laptop... I have a ThinkPad. So even on my laptop keyboard, there's no QMK, but I can use Kanata, which you've also recommended elsewhere. to try experimenting with one-shot modifiers and home row mods or other things like that that I want to, making it easier to press key bindings that have different modifiers. I don't want to have to press ctrl and shift and super all at the same time. If I set up one-shot modifiers, I can just tap tap tap and it becomes easier to press.

Prot: Yes, exactly. That opens up a lot of possibilities in terms of mnemonics, but also in terms of prefix combinations and all that. You can go a very long way.

Sacha: And I think there's a meta thing here also about getting a sense of what would make it easier for you to be able to continue enjoying this long term? Because RSI is not conducive to enjoying Emacs long term.

Prot: No. For sure. Something that I think I learned the hard way through pain is that you want to consider your desk, how you sit at the desk - you want to consider everything, not just the keyboard. For example, I have adopted a standing desk since forever. I do that all the time. I never sit, because it works better for me. I have the keyboard set up the way that makes sense to me. I can write all day. It's what I do. I don't have any pain. Whereas before I would sit on an awkward chair, the desk was not optimized, the keyboard was definitely not something I had thought of, and I had pain. It was really difficult, and I reached the point where I couldn't write. I was like, okay, I have to quit.

Sacha: If Emacs is something that pays off better in the long term, it's good to have a long term.

Prot: Exactly.

Sacha: Speaking of my very short term, in about one minute, I'm going to go off and help with the kiddos' lunch break. I very much appreciated this brain dump. This is great. I'm going to do all the usual transcription and things like that, start pulling out some of these ideas. Chat, if you found anything super interesting that you would like fleshed out into a blog post, say it so we know what to focus on for priorities, right? This was a lot of fun. Are there any key recommendations you want people to make sure they check out or is it just generally like, everyone...?

Prot: No, I think what you have here is good because, of course, you can always say more. So I will conclude with what I started. Less is more, seriously. For life, not just for email.

Sacha: Your brain is surprisingly small. If you break what you learn down into tiny steps, you have a higher chance of it actually sticking. Once you get something in, then it makes things a little bit easier. You have a little bit more space to learn the next thing, and so on and so forth. Otherwise, if you bite off too much, you get overwhelmed.

Prot: Very nice, very nice. And that ties into the lunch break. Yes.

Sacha: All right. Thank you so much. I will skedaddle and yeah, I will do all the things afterwards. Thanks everyone also for dropping by and hanging out. All right. See you around.

Prot: Take care. Take care. Goodbye. Goodbye.

You can e-mail me at sacha@sachachua.com.

"...how can people keep up with what you're learning?"¹

I've always kept a low profile on the Internet.  It can be a scary place!  But I've been asked to show glimpses of my online work to the people I was meeting in real life.

I agreed to chat with Sacha Chua about Emacs and Life (but not the Universe -- that'll be next time).  Emacs is worth revealing oneself for.  If people really do want to keep up with what I'm learning, they can visit here.

My init file² shows only a small aspect of how I have Emacs configured.  You'll want to see an example of my org file(s), my diary file, and the Lisp I have tucked away under my home directory.

Aside from Emacs, my workflow relies on Vivaldi and LibreOffice, so I'll try to show what I'm doing with them, as well.  Perhaps I can provide screen recordings, too!

"Sometimes it just takes somebody saying, your stuff is interesting. I'm telling you, your stuff is interesting."³

Thank you, again, Sacha!

Heads up for readers of this blog who are using Anju or are mouse-curious Emacs users. I’ve recently released the v1.5.0 update for it, now available on MELPA.

Many new features and enhancements are in this update as outlined below:

• Context Menus

  • Enhancements to selected text
    • Query Replace (Regexp)…
  • Enhancements to Org mode support
    • Headline
      • Change to Body
      • Sort…
    • Item
      • Cycle Bullet…
      • Sort…
    • Table
      • Sort…
    • Copy as…
    • Link…
  • Added support for Makefile mode
  • Added support for Info mode
  • Added support for Compilation/Grep mode

• Main Menu

  • Tools menu enhancements
    • Global Org Commands
    • Macro Recorder
  • Edit › Delete menu enhancement
    • Delete Duplicate Lines

Users who work with both Org mode and Markdown formatted text should find interest in the Copy as… capability added to the Org mode context menu. This feature lets one use Org mode as the primary means of authoring text, exporting to Markdown (or another format) using a right-click mouse copy action.

Thanks to Marcin Borkowski whose post “Org-mode to Markdown via the clipboard”, inspired this feature.

Anju also provides a complementary command “Paste Markdown as Org” for Org mode which lets one paste copied Markdown text into an Org file, doing the conversion of Markdown to Org under the hood using pandoc.

In summary, this is a big release with many changes. I invite you to explore all the links above to see what’s available in Anju.

Sometimes I discover an Emacs feature after an accidental keystroke. If I can remember the keystroke, I'll invoke the keystroke help (C-h k) to learn about it. Or sometimes the prompt in the mode line will suggest the function's name.

Today, the keystroke was M-z , which is bound to the function zap-to-char.

It seems to be ideal if, like me, you doze briefly while typing a senteeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

Oops, there I go again!

To fix that I can just press M-- M-z t to delete all the trailing "e" characters.

Note that M-- is invoked by holding down the Alt key while pressing hyphen. It defines a negative prefix argument, which instructs zap-to-char to "go backward," deleting all characters from point to the specified character ("t"). I'm not sure how or why you'd want the default "forward" behavior.

What accidental keystroke have you discovered recently?

Did you know that "EMACS" is a valid Wordle word?  Check it out:

A kind reader suggested I try the view-lossage command to display a list of recent keystrokes. This would be helpful for those times when I press a key accidentally and don't know what I did (as described in "zap-to-char M-z").

The output resembles what you'd get from edit-kbd-macro (assuming that a keyboard macro had been defined). This provides an alternate way to define a keyboard macro -- just select the desired portion of the output and invoke read-kbd-macro.  At this point you can "play back" those keystrokes with C-x e.

After I understood view-lossage,  I skimmed through the list of commands that start with view- (by doing M-x view- TAB). The commands view-buffer,  view-file(and variants that view in another buffer, window, frame) provide a safe (read-only) way to examine the contents of a buffer or file.

Entering M-x view-file-other-frame .emacs allows me to display my init file in a new Emacs frame and close it (by pressing "q") when I'm done with it. And then I don't have to worry about changing it inadvertently.

Today was a good Emacs day. I learned something new. Over at Ray on Emacs, Raymond Zeitler has a very nice post on using zap-to-char in reverse. He—hypothetically—was typing some text, inadvertently leaned on a key, and ended up with a long string of a repeated character at the end of his text. Something like this:

senteeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

Here’s what I didn’t know. You can cause zap-to-char to delete characters to the left by giving it negative count argument. So in Zeitler’s example, he erases the string of e​s by calling zap-to-char as Meta+- Meta+z t.

But that’s not quite right. The problem is that it will also erase the t, which I assume was not his intention. Fortunately, there’s an easy solution that I wrote about almost 14 years ago. The problem with zap-to-char is that it does what you want it to only about half the time. The rest of the time you don’t want to delete the target character; you want to delete up to but not including that character. It turns out that Emacs has a command, zap-up-to-char, to do that but it’s not bound to any shortcut¹. I have it bound to Meta+Z. It also honors the negative count argument so the correct solution for Zeitler’s problem is Meta+- Meta+Z t.

The mistake aside, this is a great post because it tells me—and maybe you—something I didn’t know: you can zap backwards.

In my last post I wrote about finally caving in and adding Magit to my config after years of being a contented vc-mode loyalist (VC-Mode Meets Magit - or Why I Finally Gave In!). My conclusion then was that the two complement each other nicely, Magit for repo-level operations, vc-mode for the everyday file-level stuff, commit a single file, a blame, a quick diff, C-x v and away you go. Well, I have just had a small but instructive lesson in not assuming where the limitations actually lie, because I caught myself about to reach for Magit for something vc-mode handles perfectly well!

The scenario: I had a pile of changes sitting in my working tree across a few files, and I wanted to set aside the changes in just one of them, temporarily, without touching anything else. Stash a single file, in other words.

I knew that vc-mode had some stash commands through the "z" keybinding when in vc-dir, and of course you can find them through M-x by completing on vc-git-stash*, but I had only ever used it for stashing everything, straight from the worktree. So I did a quick test: in vc-mode, I moved my point over a single modified file and selected vc-git-stash, but this of course would stash everything! Well, how about a single file? I assumed that vc-mode couldn't do it and reached for magit instead!

However a little niggling doubt surfaced and I decided to have a little rummage around the vc-git code:

(defun vc-git-stash (name)
  "Create a stash given the name NAME."
  (interactive "sStash name: ")
  (let ((root (vc-git-root default-directory)))
    (when root
      (apply #'vc-git--call nil "stash" "push" "-m" name
             (when (derived-mode-p 'vc-dir-mode)
               (vc-dir-marked-files)))
      (vc-resynch-buffer root t t))))

It runs git stash push -m NAME and, if you are inside a vc-dir buffer, it appends the list of marked files as a pathspec. Which means a single-file stash is built right in, no Magit required!

1. Open vc-dir with C-x v d (or C-x p v for the project-wide view)
2. Move point to the file you want to set aside and press m to mark it
3. Press z c, type a stash name, hit return

And that is it, git stash push -m "your name" -- the/marked/file runs under the hood, that one file's changes are tucked away, and everything else in your working tree is left exactly as it was. Mark two files and it stashes two, mark none and it stashes the lot, the marking is the whole mechanism.

To bring it back, z p pops a stash (it prompts you with a completing-read list of what is there)

This is almost the inverse of my last git post. Last time I went looking for vc-rebase and there genuinely was not one, a real git-specific gap that vc-mode does not fill, and off to Magit I rightly went. This time I assumed the same shape of limitation and assumed wrong, the feature was sitting there in vc-dir the whole time (and actually was pretty obvious really),

So, vc-mode really is quite capable for file-level git work, single-file stashing very much included, and I should be slower to assume "git-specific" means "Magit only". Magit is still there for the repo-level heavy lifting, but for tucking one file out of the way, C-x v d, m, z c, done, no need to leave the comfort of the built-in tooling at all.

I do enjoy these little corrections, each one teaches me a bit more about where the seams in Emacs version control actually are, and occasionally, that the seam I thought I had found was never there in the first place!

Every now and then I like to play a game of chess with my colleagues at the office, without ever leaving my favourite Elisp interpreter. Emacs has a really good package for this, chess, which supports several ways to play: against the machine, over a local network, against internet chess servers (ICS), and even through IRC (I am proud to say I finished implementing that last feature myself). You can check out the official documentation.

So I would like to share a brief introduction to playing chess over a network from Emacs.

Local network game

Lets you play directly between two Emacs sessions over TCP. You can use it to play with a friend on the same local network or VPN.

Launch it with:

C-u M-x chess RET network RET

On startup it asks which role you want:

• Server: opens a local port and waits for a connection. Uses open-network-stream-server (or nc -l -p as a fallback if not available).
• Client: prompts for a host and port, then connects.

Internet chess servers (ICS)

Maybe you have a favourite online chess provider, or you want to test your skills against players from around the world.

Launch it directly with:

M-x chess-ics

Connects to real ICS servers. The preconfigured ones are:

Supports login with a handle and password.

Playing through IRC

To play over IRC, run:

M-x chess-irc

It will connect to your configured IRC server, then ask for your opponent's nick. Your opponent needs to do the same on their end. No worries about privacy: the game uses private messages.

Note: this feature is part of my Pull Request, so if you do not see it, you may need to update your chess version or build it from the repository.

Extensions for modern platforms

There are other platforms you can play on using external packages:

• lichess.el: integration with Lichess, the most popular free chess platform.
• org-social-extension-chess.el: integration with Org Social.

Final notes

My configuration:

(use-package chess
  :ensure t
  :config
  (setq chess-images-separate-frame nil) ; Display the board in the same frame
  (setq chess-images-default-size 100))  ; Piece size in pixels

One last piece of advice: play against humans. The AI is quite easy, and while winning is fun, it is not much of a challenge. You will also get to meet more people that way. Checkmate!

I hope you enjoy your chess games inside Emacs as much as I do.

Last week I saw this post by Case Duckworth about Emacs bankruptcy but this post isn’t really about Duckworth’s post. Rather, it’s about the whole notion of Emacs bankruptcy and whether it’s something we should embrace as a routine activity. Some writers view it as part of the cycle of our Emacs life and recommend it as a regular activity.

As I wrote last year, my init.el is an organic entity that grows and adapts as my needs change. Sometimes I delete configurations or packages that I no longer use but most often I add a configuration or package as my needs change or I learn something new. I’ve put a lot of work into evolving my configuration and I can’t think of any reason that I’d want to abandon all that work and start over. Much better to fix the parts that need fixing and save the parts that are working.

My configuration is by no means a carefully considered project that has grown according to some master plan. Rather, it has evolved to meet my changing needs and newfound knowledge. Sometimes there are experiments that don’t work out and when that happens, I simply delete the offending lines and keep going.

At no point have I ever felt the need to just quit and start over. That strikes me as crazy. It is, I suppose, an Emacs specific example of the urge to scrap an existing system and rewrite it. As Joel says, that always ends in tears.

The TL;DR is that I reject the idea of Emacs bankruptcy and think that in almost every case, you should too.

Raw link: https://www.youtube.com/watch?v=xl-ifABU45A

Tomorrow, the 28th of May 2026 at 17:30 Europe/Athens time, I will join Sacha Chua’s live stream.

We will talk about the Emacs blog carnival topic for this month, which is “May I recommend”. The video will be recorded for future reference.

I already have some ideas and am looking forward to our chat!

Regular readers will be familiar with my occasional posts concerning my old pal Watts Martin’s journey into the Emacs event horizon. When he began, he swore that he would not be one of those “everything in Emacs” folks. He still (barely) hasn’t succumbed but the Borg are smiling and mumbling something about resistance and futility.

His latest step into the unknown frontiers of the black hole is adopting mu4e as his email client. It’s not an uninformed decision. Martin has tried lots and lots and email clients and mostly hates them all. As a long time Mac Head, he doesn’t care for the mu4e UI—it is, he says, the opposite of what a proper Mac app UI should be. But yet. It does have a lot of features that other mail clients don’t have. You can take a look at his post for the details.

Martin complains, rightly, that mu4e is hard to configure, especially considering that you also have to deal with isync/mbsync or something similar to retrieve email from it’s IMAP server. Longtime readers will remember my own struggles with that. I managed to avoid one of the problems that Martin dealt with by forwarding all my email accounts to a single account from which I retrieve them.

That saves a lot of trouble on the mbsync end but still allows me to handle each account separately within mu4e. If I answer an email, mu4e looks at the address the email was sent to and automatically sends it from the right address. If I initiate an email, it’s a simple matter to arrange it to be sent from any of my accounts.

Martin’s post on mu4e is actually a pretty good review of the app and worth looking at if you’re an Emacs user looking for a new email client.

As I started to write more emails to other bloggers, the annoyance with macOS' built-in email client grew. It wasn’t just the fact that it has small text that’s hard on the eyes especially on the harsh white background anymore; it just started to feel restricting.

Emacs is my natural writing environment for longer texts, like blog posts or the kind of emails I end up writing.

I’ve considered mu4e before, but setting it up seems a daunting overkill: the place I would benefit from mu4e is work, but I’m blocked by Microsoft-only 2FA authentication, so I have to stick with Outlook; meanwhile, for the three or so emails I write to other bloggers, it doesn’t require such heavy lifting.

One day about two weeks ago, I just fired up Denote, and suddenly it clicked. Denote, when you invoke it for a new note, asks for a directory - so I created an email directory in my parent Notes folder, and started writing. For a title, I use the subject, and the keyword is reserved for the recipient.

Now my eyes thank me again, as some of these emails can take an hour (and more even) to write. Links are a breeze to include, and quotes - which I use heavily in emails - are just a keyboard press away. It also looks nice when I go to the email directory and see all my drafts there, organized nicely as Denote knows how to do.

Since Denote doesn’t handle emails, for this I simply export the org file to HTML, and then with Dired (which opens in the same directory as the note I’m writing by default), I open the HTML file with my browser. From there, I copy-paste into Apple Mail, which acts as a proofread enhancer with Grammarly going to work there (this is something I’d miss if I were to use mu4e, though I could probably use Harper).

It’s a bit of a manual process, and I do need to delete the HTML files from the email directory every now and then, but for now it’s fine. It’s probably easy enough to create some shortcut that will open these HTML files directly with Mail instead of copy-pasting¹ though.

Footnotes

¹ Opening an HTML file with Dired with ! open -a Mail would make sense, but it opens Mail with the HTML file as an attachment, not as the body of the text.

I mentioned OSM for emacs briefly before, but I haven’t played with it much. That’s because the maps never showed up correctly in the buffer: the map tiles were not aligned correctly and some appeared blank.

As it turns out, someone else had this problem and also found the culprit: visual-line-mode. I have it turned on by default as the majority of my work in Emacs involves org-mode and I need my lines wrapped in the buffer. With visual-line-mode disabled, OSM works as expected, including zooming in and out. Good stuff.

Now that I fixed OSM, I was wondering about something else I wanted to do for a while: having Journelly’s latitude and longitude fed automatically to OSM in Emacs, so I can view the location on a map.

Journelly captures locations and weather information for each note and stores those under properties, like so:

PROPERTIES:
:LATITUDE: ##.##########
:LONGITUDE: ##.##########
:WEATHER_TEMPERATURE: 62.1°F
:WEATHER_CONDITION: Cloudy
:WEATHER_SYMBOL: cloud
:END:

The OSM function that calls for those is osm-goto.

So what we need is a simple function to feed the properties values directly:

(defun jtr-goto-from-properties ()
(interactive)
(let ((lat (org-entry-get (point) "LATITUDE"))
(lon (org-entry-get (point) "LONGITUDE")))
(if (and lat lon)
(osm-goto (string-to-number lat) (string-to-number lon) osm-default-zoom)
(message "No LATITUDE/LONGITUDE properties found on this entry"))))

This is an interactive function that I use when I’m standing on the header in Journelly I want to see on a map. It’s quick and works well. Now I can use my Journelly entries, which are already in org-mode, as a base for a post with a map tile inside Emacs. OSM doesn’t have a native function to export an image, but since I usually want to annotate the image anyway before I make a post out of it, a regular screen-capture app is a good solution, at least for now.

I liked the before/after snippets in Looking closer at Claude Generated Lisp Code. (Spoiler: people write nicer code.)

• Help wanted:
  • Demo site for a proposed re-design of the GNU ELPA (emacs-devel, Reddit) - feedback wanted
• Upcoming events (iCal file, Org):
  • Emacs Berlin: Emacs-Berlin Hybrid Meetup https://emacs-berlin.org/ Wed May 27 1000 America/Vancouver - 1200 America/Chicago - 1300 America/Toronto - 1700 Etc/GMT - 1900 Europe/Berlin - 2230 Asia/Kolkata – Thu May 28 0100 Asia/Singapore
  • EmacsSF (in person): coffee.el in SF https://www.meetup.com/emacs-sf/events/314950692/ Sat May 30 1100 America/Los_Angeles
  • Emacs.si (in person): Emacs.si meetup #6 2026 (v #živo) https://dogodki.kompot.si/events/67d716c3-6c04-4530-9c1a-f67aa44d31bc Mon Jun 1 1900 CET
  • EmacsATX: Emacs Social https://www.meetup.com/emacsatx/events/314809959/ Thu Jun 4 1600 America/Vancouver - 1800 America/Chicago - 1900 America/Toronto - 2300 Etc/GMT – Fri Jun 5 0100 Europe/Berlin - 0430 Asia/Kolkata - 0700 Asia/Singapore
  • M-x Research: TBA https://m-x-research.github.io/ Fri Jun 5 0800 America/Vancouver - 1000 America/Chicago - 1100 America/Toronto - 1500 Etc/GMT - 1700 Europe/Berlin - 2030 Asia/Kolkata - 2300 Asia/Singapore
• Emacs configuration:
  • Rahul Juliato: Taming Emacs Cache and Temporary Files (Reddit)
  • jamesendreshowell/emacs-config: My public Emacs configuration files - Codeberg.org (@jameshowell@fediscience.org)
• Emacs Lisp:
  • Lisp: Common Lisp, Racket, Clojure, Emacs Lisp - Hyperpolyglot (HN, lobste.rs)
• Appearance:
  • James Endres Howell: Match Emacs and GNOME light/dark theme
  • Protesilaos: Emacs: ef-arcadia and ef-atlantis are part of the ef-themes
• Navigation:
  • TIL: setting line number type to "visual" fixes relative jumping on wrapped lines
• TRAMP:
  • Using TRAMP to compile in toolbox (@cidra@mastodon.uno)
• Dired:
  • Marcin Borkowski: Marking today’s files in Dired (Irreal)
• Writing:
  • TAONAW: Checking grammar with Harper
• Denote:
  • Protesilaos: Emacs: Denote version 4.2.0
• Org Mode:
  • Org Mode requests: [RFC] org-agenda log-mode is very confusing
  • Org Mode requests: [FR] support footnote inline displaying & navigation
  • Wai Hon: Refining Org-mode Deadlines
  • You can do what with org agenda? (08:54)
  • How I finally hid stars in front of org headings while also using org-indent
  • Vineet Naik: tagref can now be used with org-mode files
  • build blog with orgmode and github pages (@lobocode@hachyderm.io)
  • Annotate-in-Place Notes with Emacs and org-remark (YouTube 18:15, r/orgmode, r/emacs, HN, Irreal)
  • Navi - Personal Org-Roam Graph Window - Reads DB directly - Feedback? (Reddit)
  • org-roam-gt: faster node search and richer capture targets for org-roam (Reddit)
  • grove-extra.el – some extras on top of grove.el (fa2 graph, md etc.) (Reddit) - grove is a note-taking mode
• Completion:
  • dl-completion: Custom completion-style (Reddit)
  • vertico-carousel: keep the selected Vertico candidate on the first visible row (Reddit)
• Coding:
  • A small write-up of git blaming in Emacs (Reddit)
  • Dave Pearson: next-gh-pr.el v1.0.0
  • Bozhidar Batsov: neat: a language-agnostic nREPL client for Emacs
  • sdkman.el — per-project SDKMAN environments in Emacs
  • Jakub Nowak: New Job: Jira Integration
• Math:
  • ratex.el: A live preview latex math package. (Reddit)
• Mail, news, and chat:
  • Doom Emacs Mail Sending and Python Way (03:15)
• AI:
  • Looking closer at Claude Generated Lisp Code | skybert.net (@skybert@hachyderm.io)
  • Emacsclient landed in Gemini CLI, and why I won't contribute to non-FOSS projects again
  • martenlienen/emcp: An MCP server for Emacs - Codeberg.org (@martenlienen@hachyderm.io)
  • An experimental Markdown renderer by xenodium · Pull Request #597 · xenodium/agent-shell · GitHub (@xenodium.bsky.social)
• Community:
  • Fortnightly Tips, Tricks, and Questions — 2026-05-19 / week 20
  • Concerning Emacs (and Jazz)
  • "May I recommend thinking of Emacs as your Fortress of Solitude" (Reddit)
  • Brazilians in the community 🇧🇷 - organizing get-togethers or a communications channel?
  • Sacha Chua: Emacs Chat 23: Emacs Chat with Raymond Zeitler (YouTube, 58:44)
  • #Emacs #Embark with Omar Antolin, Ramin Honary and Kent Pitman #lisp and more #interview #lispyGopherClimate - toobnix (1:12:40, Reddit)
  • From Emacs to Agents - Vivek Haldar shifting away from Emacs for now
  • Apropos with Bozhidar Batsov - YouTube (@bbatsov@hachyderm.io)
  • Amin Bandali: Thinking about life - chat with Protesilaos (Prot)
• Emacs development:
  • Re: emacs-31 142b1e0d4c3: Fix Lisp injection via X-Draft-From in Gnus - Eli Zaretskii
  • Why braces instead of casts (Re: master 56ae704e5b2 1/7: Fix (ash -1 1) undefined behavior - Paul Eggert)
• Other:
  • Faça o Emacs olhar para o dinheiro usando o Embark (15:44)
  • May I recommend using your thumbs (Irreal)
  • my i3-emacs integration (HN) i3 is a window manager
  • caffeinate-mode: Prevent your system from sleeping using the native power assertion API in Emacs 31+ (Reddit)
  • A possible security layer for emacs
• New packages:
  • clutch: Interactive database client (MELPA)
  • ffs: Form feed-separated plain text presentations (GNU ELPA)
  • fzf-native: Fuzzy completion style (MELPA)
  • meshtastic: Chat client for Meshtastic LoRa devices via serial (MELPA)
  • use-package-x: Additional keywords for use-package (MELPA, Reddit)

Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, Mastodon #emacs, Bluesky #emacs, Hacker News, lobste.rs, programming.dev, lemmy.world, lemmy.ml, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar, and emacs-devel. Thanks to Andrés Ramírez for emacs-devel links. Do you have an Emacs-related link or announcement? Please e-mail me at sacha@sachachua.com. Thank you!

You can e-mail me at sacha@sachachua.com.

For a long time, I didn't use deadlines in Org-mode at all. However, over the past year (or perhaps even longer, though I forget exactly when), I have found myself relying on them more and more. Deadlines have quietly become the backbone of my day-to-day productivity.

A New Prioritization Hierarchy

In my earlier post on task management workflow, my day-to-day focus was heavily centered around scheduled dates and TODO states. Today, my prioritization hierarchy has fundamentally evolved to:

Deadline + Priority > Schedule > TODO States

• Deadlines + Priorities represent my primary focus. Deadlines show what must be delivered and when, while priorities help determine which deadline to tackle first. Together, they serve as the main driver for my planning.
• Scheduled dates are reserved for habits, recurring chores, or temporary "snoozing" (hiding tasks until they need to be revisited).
• TODO States (like NEXT or PROG) act as a backlog of next actions. If my deadline and prioritized items are blocked or completed, I look here to see what to pick up next.

Default Org Agenda View

However, the default deadline behavior in Org-mode didn't really work for me. Out of the box, deadlines look identical to scheduled tasks, and the short warning window makes them hard to plan around.

Here is the default Org agenda view:

Customized Org Agenda View

To support this deadline-first workflow, here are two tricks I used to turn Org-mode deadlines into a powerful planning tool.

Here is the customized Org agenda view:

;; Shorten the leaders to reserve spaces for the repeater.
(setq org-agenda-scheduled-leaders '("Sched" "S.%2dx"))
(setq org-agenda-deadline-leaders '("🔴 0d" "🔴%2dd" "🔴-%1dd"))

(defun my/org-agenda-repeater ()
  "The repeater shown in org-agenda-prefix for agenda."
  (let ((pom (org-get-at-bol 'org-marker)))
    (if (or (org-get-scheduled-time pom) (org-get-deadline-time pom))
        (format "%5s: " (or (org-get-repeat) ""))
      "------------")))

;; Add repeater and effort to the agenda prefixes.
(setq org-agenda-prefix-format
      '((agenda . " %i %-12:c%?-12t%s%(my/org-agenda-repeater)")))

;; Add deadline-up to agenda to separate schedule and deadline.
(setq org-agenda-sorting-strategy
      '((agenda deadline-up habit-down time-up priority-down category-keep)))

(setq org-deadline-warning-days 35)

DEADLINE: <2026-06-19 Fri ++28d -3d>

I wrote about Harper before, but I wanted to expand now that I have it working on Kubuntu with a couple of more options.

Harper is good in two scenarios for me: first, when I want something quick and I don’t feel like starting a browser with Grammarly in it, and second, when I write a personal email and the idea of my words going to some AI grammar bot somewhere makes my skin crawl. Otherwise, for my blog (which is public anyway) and work email (I don’t care about those) Grammarly is definitely better.

The issue with Linux is that the makers of Harper geared it toward macOS (Homebrew) and Arch Linux, among other things. It was made for programmers by programmers, and these guys don’t bother with Ubuntu-like distros. Fair, but up until recently it meant I had to jump through hoops.

The quick and easy route in Ubuntu distros (which is what Kubuntu is) is to use snap. I know, I know. I didn’t want to either, but since the Harper makers don’t bother with flatpak, the other option was to install a Rust environment, which is a big overkill just for an app inside Emacs I use like once a month or so or less. I don’t like snap and I don’t use it, but I made an exception here.

Now, that snap “shortcut” is by a guy who works with Ubuntu (I think) and maintains his own package for it, so it’s on the edge channel (not stable) and seems to be a lot behind (version .49 to be exact, and Harper is currently 2.2.1!) so if Harper is your choice of grammar check, and you use it daily, I’d suggest against what I’m doing below. I’d install as needed in that case, Rust and all.

With that disclaimer, let’s move on: sudo snap install harper --edge.

Now in Emacs, in Linux, we want to tell it where harper is:

    (when (eq system-type 'gnu/linux)
               (add-to-list 'exec-path "/snap/harper/current/bin"))

When tells it to add the snap path only when running Linux, since I have the same config for both macOS and Linux.

That’s all… After that, I’ve added some of Harper’s flags, or linters. Here’s the whole code as I have it in my emacs org settings:

          (with-eval-after-load 'eglot
            (add-to-list 'eglot-server-programs
                         '(org-mode . ("harper-ls" "--stdio"))))
    
           (setq-default eglot-workspace-configuration
                      '(:harper-ls (:dialect "American" :linters (:LongSentences :json-false :AvoidCurses :json-false))))
    
    ;; Besides choosing American as the language, I also want to ignore long sentences (the main issue is that it hides other errors nested in those) and I also want harper not to tell me when it thinks something is offensive. The full list of these options is in https://writewithharper.com/docs/rules. It needs to be nested inside the :linters option.
    
           (when (eq system-type 'gnu/linux)
             (add-to-list 'exec-path "/snap/harper/current/bin"))
    
    ;; on a mac, Harper is installed via Homebrew - on Kubuntu, the best option is snap - the harper team does not do a package (flatpak) unfortunately, and I don't want to install Rust just for harper. So.. meh.  I did sudo 'snap install harper --edge' for this.

John Gruber has a very interesting—at least for those of us who obsess about typography—post on the fonts used by the various federal courts of appeal. For those of you who don’t know, the courts are very strict about the written format of their decisions and of the briefs filed with them. Not only is there a fixed and rigid format, the font used is also specified. Failure to adhere to the standard is prima facie reason for rejecting the filing. That said, each district has it’s own standards and choice of font. Some of those are particularly ugly versions of Courier and others are beautiful fonts such as Century Schoolbook and Equity.

The Supreme Court—which used to insist on hot-metal typeset documents—uses Century Schoolbook. Take a look at Gruber’s post for the interesting details.

None of this would be Irreal fodder except for a thread on the TUHS mailing list about LaTeX versus Troff for typesetting. Some of the discussion involved the difference between the input languages but a surprising amount talked about fonts as if Troff was still being run on a C/
A/T typesetter with a single fixed font. In fact, both typesetters can use just about any font although it is true that the output from each does have a distinctive look.

I wrote two books for a major publisher and typeset them using Troff so at the time I could probably have been considered a Troff expert. Then I started using Lisp and partly as a result I moved to Emacs. Since then, I do all my writing in Org mode, which, of course, uses LaTeX for producing typeset output.

Sadly, these days I can’t be considered an expert in either Troff or LaTeX but it doesn’t really matter because Emacs has me covered. I simply write in Org mode and get great results for printed content. I still know enough LaTeX to tweak my results if I need to so I have the best of both worlds: the ease of Org and the power of LaTeX.

In the recent weeks I've been engaging Prot as a coach to help review my new ffs package for GNU Emacs as I worked on preparing it for inclusion in GNU ELPA, as well as discussing other Emacs- and life-related topics.

UPDATE 2026-05-23 22:39:15 -0400: Prot also published an article about our session on his website: https://protesilaos.com/commentary/2026-05-23-life-issues-and-philosophy-amin-bandali/

In our nearly 2-hour conversation, we discussed at length and in depth various aspects of life in the current times. For instance, feeling overwhelmed in the face of innumerable things happening at once, with technology changing our perception and making events feel proximate and imminent.

We talked about seasonality and rhythms in life, including in relation to burnout and knowing our own limitations, and descriptive vs prescriptive thinking when reflecting on the expectations we may place on our self when comparing our self to others through the lens of our necessarily-incomplete impressions and glimpses of their lives. We discussed absence or loss as a dual to presence or persistence in the process of life. How with our memories and through embodying the philosophy and teachings of departed loved ones their essence and legacy continues to live on within us. But also loss in the sense of us losing parts of our self in life-defining moments while preserving other parts and gaining new ones, being liberated of some of the burdens of our past self and in effect becoming someone else in the process.

In being true to our self, we talked about humans as multi-faceted beings and the importance of expressing and giving a voice to these different aspects of our self, and keeping alive that child-like sense of awe and wonder. To live a life where the pace and rhythms of our environment are in sync with our internal rhythms, and to not give others undue power over us or our happiness through trying to live according to their prescribed standards or expectations.

I also learned more about Prot's practical philosophy of situational awareness in life, not merely as a means for survival, but also as a way of appreciating all of the beauty that surrounds us, and a method for gaining the knowledge and skills to apply what we learn from patterns in one area of life to other areas.

We concluded our session with a mention to the concept of sanctity, to set aside a sacred time or place for our self wherein no distractions are allowed, where we can unwind, rest, and recharge for whatever comes next.

Here is the video recording of our session, which I share with Prot's permission:

You can view or download the full-resolution video from the Internet Archive.

Like Prot, I am invigorated and inspired to live a full, honest life. To do my best, do what I do in earnest, and make the best of what I have.

Take care, and so long for now.

Emacs’ shortcuts and their role in RSI are a staple of Emacs commentary. Everyone, it seems, has their own methods for relieving stress on their hands as they use Emacs. Prot, for example, thinks that one-shot modifiers are the answer. Others recommend using a split keyboard or simply mapping Caps Lock to Ctrl.

A post over at meanwhiling has another suggestion: use your thumbs. That’s also familiar advice but the post goes into specific details. Those details, in a nutshell, are to map the two keys nearest to either side of the space bar to Ctrl and the two keys next to those to Meta.

That setup has the advantages that

1. Both the Ctrl and Meta keys can be pressed with a thumb
2. There is a Ctrl and Meta key on both sides of the keyboard so you never have to press the modifier and target key with the same hand.

The only remaining question is what to do about Hyper and Super. I use both of those, especially Hyper, all the time so I need them easily accessible. That’s made easier for me because I don’t mind using the same hand for the modifier and target keys. I still use Caps Lock for Ctrl and my thumbs for everything else. If my pinky ever starts complaining about Ctrl I’ll probably just swap Ctrl and Super. I’d do that anyway except for muscle memory and the fact that my hands don’t hurt.

I do think using your thumbs for your most used modifiers make sense and modern keyboards make that pretty easy to set up.

This month’s Emacs Asia-Pacific (APAC) virtual meetup is scheduled for Saturday, May 23, 2026 with BigBlueButton and #emacs on Libera Chat IRC. The timing will be 1400 to 1500 IST.

The meetup might get extended by 30 minutes if there is any talk, this page will be updated accordingly.

If you would like to give a demo or talk (maximum 20 minutes) on GNU Emacs or any variant, please contact bhavin192 on Libera Chat with your talk details:

You open your favorite editor, and, out of the box, Emacs writes state files all over the place. It puts bookmarks in ~/.emacs.d/, drops #auto-saves# next to every file you edit, leaves .~lockfiles~ in your projects, scribbles recentf, history, saveplace, projects, transient/history.el, tramp, network-security.data, multisession/, url/, image-dired/, erc/, rcirc/... you get the picture. The features are great, don't get me wrong. The default locations are what annoy me.

Most of those files are not noise. They are the state that makes Emacs feel like Emacs across restarts. So you cannot just delete them. But you also do not want them spread across N different directories with cryptic names. (I know I don't.)

I want one directory I control, every cache-bound variable pointing inside it, and a switch to flip it between "persistent inside my config" and "ephemeral in /tmp". No external package, no naming scheme to memorize, just a small pattern I can read top to bottom in init.el.

My emacs-solo config used to hard-code a single relative path under user-emacs-directory for all these cache files. It worked, but it was inflexible. A user opened an issue asking if the cache location could be changed without forking the config, since they wanted those files somewhere else entirely. So I redesigned it around a defcustom root and an alist of relative paths, switchable through M-x customize. The version below is the same idea with the emacs-solo names dropped.

Our goal

Patch these three pieces:

→ cache directory: holds every piece of mutable state Emacs writes during a session.

→ alist map: lists every variable that needs to be pointed at that directory.

→ helpers: one resolve a key to an absolute path, and another pre-creates every directory so we never get "no such file or directory" warnings at startup.

In practice, a .emacs.d directory ends up looking like this:

.
├── cache
│   ├── auto-saves
│   ├── erc
│   ├── image-dired
│   ├── multisession
│   ├── rcirc
│   ├── transient
│   ├── url
│   └── ...
├── eln-cache
│   └── 32_0_50-25c5b284
├── eshell
│   └── history
├── init.el
└── tree-sitter
	├── libtree-sitter-markdown-inline.dylib
	└── libtree-sitter-markdown.dylib

Our switchable base directory

Start with a defcustom for the root. Using defcustom (instead of defvar) lets you change the value through M-x customize without editing init files, and the choice persists in custom.el:

(defcustom my/cache-directory
  (expand-file-name "cache/" user-emacs-directory)
  "Base directory for Emacs cache files.
All entries in `my/cache-paths' are resolved relative to this
directory.  Choose one of the presets or supply any custom path.
Changes take effect after restarting Emacs."
  :type `(choice
		  (const     :tag "Inside Emacs config  (cache/ in user-emacs-directory)"
					 ,(expand-file-name "cache/" user-emacs-directory))
		  (const     :tag "System temp          (/tmp/emacs-cache/)" "/tmp/emacs-cache/")
		  (directory :tag "Custom directory"))
  :group 'my)

The default puts everything under ~/.emacs.d/cache/, which keeps the rest of ~/.emacs.d/ clean and lets you back up or delete the whole cache as one directory. The /tmp/ preset is for sessions that should leave no trace. The directory choice lets you point at any custom path.

I use user-emacs-directory instead of a literal ~/.emacs.d/ because Emacs 29 added the --init-directory flag, which lets you launch Emacs against any config directory. I use it constantly to try other people's configs side by side with my own without touching ~/.emacs.d/. Anchoring on user-emacs-directory means the cache follows whichever config Emacs was started with, instead of every alternate config writing into the default ~/.emacs.d/ and stepping on each other.

In my early-init.el I already load custom-file, but I reload it here too. customize writes its changes to custom.el immediately, so if you change the cache directory mid-session through M-x customize and then restart, you want the new value to apply before the rest of init.el runs and calls my/cache--path:

(when custom-file
  (load custom-file 'noerror 'nomessage))

The when guard is there because in a brand-new config custom-file is nil, and (load nil 'noerror 'nomessage) signals (wrong-type-argument stringp nil) and aborts the rest of init.el. The 'noerror flag suppresses file-error, not type errors.

This whole reload is a bit of a hack. Loading custom-file twice during startup just to get a defcustom value hot before the next form is not what Emacs intends. It only matters the first time you switch presets. Without it, you would wonder why your new /tmp/emacs-cache/ is empty while your old ~/.emacs.d/cache/ keeps receiving writes.

Our single alist as the source of truth

The next piece is the mapping from keys to relative paths.

How you organize this alist is your call. The list below is what I wire through my/cache-path in my own config, but plenty of users will split things differently. I deliberately keep tree-sitter/, eln-cache/, and eshell/ outside this alist. tree-sitter and eln-cache are populated by long-running, expensive processes (grammar compilation, native compilation) that I want to survive when I reset my cache, so they live next to the config under user-emacs-directory directly. eshell carries my command history and aliases, which I treat more like dotfiles than throwaway state. Your workflow will pull these differently, and that is fine.

(defvar my/cache-paths
  '(;; Files:
	(bookmark-file               . "bookmarks")
	(ielm-history-file-name      . "ielm-history.eld")
	(project-list-file           . "projects")
	(recentf-save-file           . "recentf")
	(savehist-file               . "history")
	(save-place-file             . "saveplace")
	(transient-history-file      . "transient/history.el")
	(transient-levels-file       . "transient/levels.el")
	(transient-values-file       . "transient/values.el")
	(tramp-persistency-file-name . "tramp")
	(nsm-settings-file           . "network-security.data")
	;; Directories:
	(auto-saves                  . "auto-saves/")
	(auto-saves-sessions         . "auto-saves/sessions/")
	(multisession-directory      . "multisession/")
	(url-configuration-directory . "url/")
	(image-dired-dir             . "image-dired/")
	(erc-log-channels-directory  . "erc/logs/")
	(erc-image-cache-directory   . "erc/images/")
	(rcirc-log-directory         . "rcirc/logs/"))
  "Alist of (KEY . RELATIVE-PATH) for cache locations.
RELATIVE-PATH is resolved against `my/cache-directory'.
A trailing slash on RELATIVE-PATH marks the entry as a directory.")

The convention I follow: keys are usually the names of the Emacs variables they will fill. That keeps grep useful for both the definition and the usage.

A trailing slash on the value marks a directory (this matches directory-name-p in Emacs). No trailing slash means a file. The next helper uses that distinction.

Our helpers

The first helper turns a key into an absolute path:

(defun my/cache--path (key)
  "Return the absolute path for KEY in `my/cache-paths'."
  (let ((rel (cdr (assq key my/cache-paths))))
	(unless rel
	  (error "my/cache--path: Unknown key %S" key))
	(expand-file-name rel my/cache-directory)))

assq does an eq lookup on symbol keys. The unless rel branch is there because typos in :custom blocks are silent otherwise: you would get nil and Emacs would happily write to nil, which fails in confusing ways. Better to error at config load.

The second helper pre-creates every directory the alist mentions, so we never get "directory does not exist" warnings from packages on first run:

(defun my/cache--ensure-dirs ()
  "Create every directory referenced by `my/cache-paths'.
Entries ending in `/' are created directly; other entries have their
parent directory created."
  (dolist (entry my/cache-paths)
	(let* ((abs (my/cache--path (car entry)))
		   (dir (if (directory-name-p abs)
					abs
				  (file-name-directory abs))))
	  (make-directory dir t))))

(my/cache--ensure-dirs)

If the entry is a directory (directory-name-p returns t for values ending in /), it is created as-is. If the entry is a file, only the file's parent directory is created.

The t argument to make-directory is the "parents" flag, the equivalent of mkdir -p. So transient/history.el correctly creates <cache>/transient/ even though we never list it explicitly.

Wiring it into use-package :custom

Now every cache-bound variable points at our helper. Inside a use-package emacs block (or wherever you set built-ins):

(use-package emacs
  :ensure nil
  :custom
  (bookmark-file              (my/cache--path 'bookmark-file))
  (ielm-history-file-name     (my/cache--path 'ielm-history-file-name))
  (project-list-file          (my/cache--path 'project-list-file))
  (recentf-save-file          (my/cache--path 'recentf-save-file))
  (savehist-file              (my/cache--path 'savehist-file))
  (save-place-file            (my/cache--path 'save-place-file))
  (transient-history-file     (my/cache--path 'transient-history-file))
  (transient-levels-file      (my/cache--path 'transient-levels-file))
  (transient-values-file      (my/cache--path 'transient-values-file))
  (nsm-settings-file          (my/cache--path 'nsm-settings-file))
  (multisession-directory     (my/cache--path 'multisession-directory))
  (url-configuration-directory (my/cache--path 'url-configuration-directory))
  ;; The two below are *not* backups; they keep auto-save state
  ;; without scattering `#file#' next to every edited buffer.
  (create-lockfiles  nil)   ; no `.#file' lock files at all
  (make-backup-files nil)   ; no `file~' tilde backups at all
  (auto-save-default t))    ; auto-save *is* kept, just redirected below

On the three settings at the bottom:

→ create-lockfiles nil and make-backup-files nil are personal taste. Lockfiles warn another Emacs not to clobber your buffer, but they break frontend tooling that watches directories for changes (TypeScript, Vite, esbuild). The tilde backups I find redundant with modern VCS and auto-save.

→ auto-save-default t stays on because auto-save is what rescues you when Emacs crashes. We just want it somewhere else.

Redirecting auto-saves

Auto-save needs two extra settings because Emacs uses path transforms for it instead of single-value variables:

;; We want auto-save, but no #file# cluttering, so everything goes
;; under our cache/ tree. Directories are pre-created.
(setq auto-save-list-file-prefix (my/cache--path 'auto-saves-sessions)
	  auto-save-file-name-transforms
	  `((".*" ,(my/cache--path 'auto-saves) t)))

auto-save-list-file-prefix controls where the "list of files with pending auto-saves" lives. This is what M-x recover-session reads. Pointing it at our auto-saves/sessions/ directory means you can still recover after a crash, without ~/.emacs.d/auto-save-list/ cluttering your config.

auto-save-file-name-transforms is a list of (REGEX REPLACEMENT UNIQUIFY) triples. The t at the end is the uniquify flag, which encodes the original path into the filename so two files with the same name in different directories do not collide in the auto-save folder.

Both end up in <cache>/auto-saves/.

TRAMP, viper, and other late bindings

Some variables are not safely set in :custom, because they are defined inside packages that load later. For those, use setopt (which respects defcustom setters) inside the :config block:

(setopt tramp-persistency-file-name (my/cache--path 'tramp-persistency-file-name))
(setopt viper-custom-file-name      (my/cache--path 'viper-custom-file-name))

setopt is the modern equivalent of setq for customizable variables. It runs any :set function the variable defines, which tramp-persistency-file-name does (it triggers a reload). Plain setq would skip that and leave TRAMP confused.

What you get

→ ~/.emacs.d/cache/ (or wherever you point it) contains everything. du -sh tells you how much state Emacs is hoarding. rm -rf resets it all without touching your config.

→ M-x customize-variable RET my/cache-directory lets you flip between persistent and ephemeral modes without editing init files. Useful for screencasts where you want zero history showing, or for testing whether a problem is config or state.

→ New packages are a two-line change. When you adopt, say, newsticker, you add one entry to my/cache-paths and one (my/cache--path 'newsticker-dir) line in the package's :custom. The directory is auto-created on next restart.

→ You can grep for it. grep my/cache--path init.el lists every place Emacs writes state, and the alist tells you what kind.

The complete code

Here is everything in one block. Copy this into some temporary folder inside the init.el file. After that, cd into this temp directory and run emacs --init-directory=./. You can them navigate files, use Emacs features and check where the created files end up to.

(defcustom my/cache-directory
  (expand-file-name "cache/" user-emacs-directory)
  "Base directory for Emacs cache files."
  :type `(choice
		  (const     :tag "Inside Emacs config  (cache/ in user-emacs-directory)"
					 ,(expand-file-name "cache/" user-emacs-directory))
		  (const     :tag "System temp          (/tmp/emacs-cache/)" "/tmp/emacs-cache/")
		  (directory :tag "Custom directory"))
  :group 'my)

(when custom-file
  (load custom-file 'noerror 'nomessage))

(defvar my/cache-paths
  '(;; Files:
	(bookmark-file               . "bookmarks")
	(ielm-history-file-name      . "ielm-history.eld")
	(project-list-file           . "projects")
	(recentf-save-file           . "recentf")
	(savehist-file               . "history")
	(save-place-file             . "saveplace")
	(transient-history-file      . "transient/history.el")
	(transient-levels-file       . "transient/levels.el")
	(transient-values-file       . "transient/values.el")
	(tramp-persistency-file-name . "tramp")
	(nsm-settings-file           . "network-security.data")
	;; Directories:
	(auto-saves                  . "auto-saves/")
	(auto-saves-sessions         . "auto-saves/sessions/")
	(multisession-directory      . "multisession/")
	(url-configuration-directory . "url/")
	(image-dired-dir             . "image-dired/")
	(erc-log-channels-directory  . "erc/logs/")
	(erc-image-cache-directory   . "erc/images/")
	(rcirc-log-directory         . "rcirc/logs/"))
  "Alist of (KEY . RELATIVE-PATH) for cache locations.")

(defun my/cache--path (key)
  "Return the absolute path for KEY in `my/cache-paths'."
  (let ((rel (cdr (assq key my/cache-paths))))
	(unless rel
	  (error "my/cache--path: Unknown key %S" key))
	(expand-file-name rel my/cache-directory)))

(defun my/cache--ensure-dirs ()
  "Create every directory referenced by `my/cache-paths'."
  (dolist (entry my/cache-paths)
	(let* ((abs (my/cache--path (car entry)))
		   (dir (if (directory-name-p abs)
					abs
				  (file-name-directory abs))))
	  (make-directory dir t))))

(my/cache--ensure-dirs)

(use-package emacs
  :ensure nil
  :custom
  (bookmark-file               (my/cache--path 'bookmark-file))
  (ielm-history-file-name      (my/cache--path 'ielm-history-file-name))
  (project-list-file           (my/cache--path 'project-list-file))
  (recentf-save-file           (my/cache--path 'recentf-save-file))
  (savehist-file               (my/cache--path 'savehist-file))
  (save-place-file             (my/cache--path 'save-place-file))
  (transient-history-file      (my/cache--path 'transient-history-file))
  (transient-levels-file       (my/cache--path 'transient-levels-file))
  (transient-values-file       (my/cache--path 'transient-values-file))
  (nsm-settings-file           (my/cache--path 'nsm-settings-file))
  (multisession-directory      (my/cache--path 'multisession-directory))
  (url-configuration-directory (my/cache--path 'url-configuration-directory))
  (create-lockfiles            nil)
  (make-backup-files           nil)
  (auto-save-default           t)
  :config
  (setq auto-save-list-file-prefix (my/cache--path 'auto-saves-sessions)
		auto-save-file-name-transforms
		`((".*" ,(my/cache--path 'auto-saves) t)))
  (setopt tramp-persistency-file-name (my/cache--path 'tramp-persistency-file-name)))

Adapt the alist to the packages you actually use.

Other Resources

If you want to read more on the topic:

→ https://www.gnu.org/software/emacs/manual/html_node/emacs/Auto-Save-Files.html

→ https://www.gnu.org/software/emacs/manual/html_node/elisp/Variable-Definitions.html#index-defcustom

If you would rather install a package than maintain your own alist, the no-littering package is a popular ready-made alternative that covers a wide set of variables out of the box.

The version of this code I actually run, alist entries and all, lives in my emacs-solo config under the CACHE PATHS heading of init.el. If you end up adapting this for your own setup, I would love to hear which variables you added that I forgot.

Icon

Product: BBEdit 16
Price: $60 for new version, $30 for upgrade from version 15, $40 for upgrade from versions prior to that. Mac App Store version pricing is different.

BBEdit keeps to an upgrade schedule of about two and a half years between major versions. It is about that time and there is a new version of BBEdit. Version 16.

It is accompanied as usual by extensive release notes. This is the one product whose release notes I love reading. They are extensive and they are sometimes funny. The developers believe that it is important to document the changes to the program and they are serious about that. I wish more programs did that. It shows a care for their customers and their craft.

What Is New?

• Expanded Shortcuts support. This is going to be useful to the heavy user of macOS Automations and BBEdit. I have not explored this much.
• Search for text in images. Sure this is useful. But I have other tools to do this for me.
• Color Customizations for Projects and Notebooks. I like this. I have a couple of projects and a couple of notebooks always open in BBEdit. Using different themes gives me a visual cue to identify them. Useful.
• AI Chat Worksheets improvements. I am sure this is important to some people, I am not interested in this.

There are a whole host of other changes. One of them stuck out to me:

• Support for vi keyboard emulation, for basic navigation and editing. There are a whole host of users who swear by vi keyboard commands. They are going to be ecstatic. I am ambivalent. I use Emacs keybindings. I also like the native BBEdit keybindings. I have been using this program for about twenty years.

A Tangent

BBEdit has a problem. It is a mature program with a feature-set which has been honed over a long time (since 1992). It has old-school roots. No bold, no italic. They take the concept of being a “text-editor” seriously. The product is not user-extendable in any meaningful way.

Yes. You can write an AppleScript, Text Factories, even themes (although for a product this old, there is a strange paucity of themes). But the base product is not user-extendable. It is not VSCode, Zed, Sublime Text, VIM, or Emacs. You will never see something like Org-mode written for BBEdit. It is not designed for that.

But it has a repeatable two and a half year upgrade cycle. What do you add? What do you highlight as the new great feature which will make existing users upgrade or new users adopt? How do you keep up with the Jones’s? Or in this case, the VSCode’s, and the Zed’s of the world?

What brought this tangent on? I looked at the vi implementation. Nowhere in the abundant documentation of the product does the developer provide a listing of the commands they support. Check out Zed’s documentation for VIM keybindings as a comparison. They are extensively documented and continuously improved. BBEdit is quiet about the details. Why? This is a feature which some customers have been asking for, for a long time. Actually when it comes to VIM keybindings, people who love them want them everywhere and they are a vocal bunch, so every editor launched has to face this clamor. BBEdit gives in to the demand, but somewhat reluctantly. “I am going to implement it, but I am going to keep quiet about the details.” Why?

To me, BBEdit is a program which is being dragged into the world of modern text editors, scratching and screaming. You want minimaps? How does this look to you?

minimap

You want a command palette?

Command Palette?

The command palette lists commands and files. What? A file is not a command. I am sure that the developer knows that.

It is an attempt to replicate what the competition is doing but the implementation is half baked. The reasons might be technical limitations, or it might be lack of commitment, but the effect is underwhelming. VI keyboard implementation is another example of that.

BBEdit is by design not extendable. Which means no third-party extensions/packages. What the developer gives you is all you are going to get. This leaves it vulnerable to new editors like VSCode and Zed with their built in extensions support. It is also not competitive with old editors like VIM (neovim) or Emacs. Both of them have an extensive ecosystem of extensions and packages. The ecosystem around these competitors make BBEdit look ancient and more distressingly, restrictive.

I am obviously biased in this evaluation. I use Emacs. I am also not a developer. I am a writer. I write in Markdown and Org-mode. Markdown is better implemented in Emacs. BBEdit doesn’t do Org-mode. It is not close. They are different worlds. Org-mode can do things which BBEdit cannot dream of.

Maybe BBEdit should make a conscious decision to be what it is. A fantastic old-school text editor, which is secure, stable and efficient at slinging around text. Concentrate on the following areas where you have a competitive advantage:

• macOS automation.
• Supporting native macOS features. Versions, keyboard commands, Text Replacements, and the like.
• Explore the concept of Notebooks more thoroughly. Linking between documents and sections within documents would be a great addition.

The two and a half year upgrade cycle? I have no answer for that.

Disorganized Thoughts

If you are an user who is new to text editors try out the free version of BBEdit. Look at VSCode and Zed as capable free alternatives.

If you are writing Markdown and that is what you are using a text editor for, iA Writer and MarkEdit are better. Their support for Markdown is better.

If you are interested in note-taking. Obsidian is better.

If you are an existing paid user, you know the product, make the best call for you. If you are using the free version, upgrade.

If you are interested in building a life around text files, Emacs is the better option. Remember that the learning curve is pretty steep in Emacs. BBEdit has a smoother learning curve, but for the esoteric features of BBEdit you need to read the manual. Thankfully that comes with the program and it is excellent.

Don’t be fooled by the rhetoric on “Mac-assed” application and how BBEdit embodies that. Firstly “Mac-assed” is a nebulous descriptor and I would argue that Zed is as “mac-assed” as BBEdit. Or iA Writer is more “mac-assed” than BBEdit. Think versions and text replacement support.

So who should buy BBEdit 16?

• Existing users who love BBEdit.
• Those looking for a stable, efficient text editor which comes with excellent support and extensive documentation.
• Those looking for an editor which handles large files with no problems. BBEdit is good at that. They are not the only solution for that feature. Zed is good at that too. And Zed does that with excellent syntax highlighting.

Conclusion

BBEdit 16 is underwhelming. I like some of the additions but they are not crucial to me. Heavy users of BBEdit might have a different take on the nature of the update.

I think that BBEdit is near the end of its justified existence. This was my take on version 13: BBEdit 13: It Sucks a Little - Bicycle For Your Mind. On version 14: BBEdit 14 Protects You From “Untitled Text” Infestation - Bicycle For Your Mind. I was so underwhelmed by version 15, that I didn’t write about it.

Version 16 is not much different. It doesn’t introduce much by the way of new features and it doesn’t fix some of the glaring inconsistencies from previous versions (Commands can’t include files, that is just dumb, and has been this way since version 14).

I can recommend the free version of BBEdit.

The paid version? Not for the new user. Dependent on your needs there are better alternatives available to you. It is a good idea to explore them before you adopt BBEdit.

macosxguru at the gmail thingie.

Update: Another take on BBEdit 16. BBEdit 16 Searches for Text in Images, Adds Shortcuts Actions, and More - TidBITS

ffs provides a minor mode for simple plain text presentations in Emacs, where the slides are separated using the page-delimiter, by default the form feed character (^L).

I wrote ffs in early 2022 for my LibrePlanet 2022 presentation the Net beyond the Web, and earlier this year decided to polish it towards being a proper package and submit it to GNU ELPA. The manual still needs some more work, but the overall package is in pretty good shape so I submitted for inclusion in GNU ELPA.

• Package name (GNU ELPA): ffs
• Official manual: https://kelar.org/~bandali/gnu/emacs/ffs.html
• Change log: https://kelar.org/~bandali/gnu/emacs/ffs-changelog.html
• Git repository: https://git.kelar.org/~bandali/ffs
• Backronyms: fabulous foolproof slides - for freedom's sake - ffs flips slides

ffs and I owe a debt of gratitude to Protesilaos for rounds of code review and feedback for improving and polishing the package in preparation for submission to GNU ELPA. You can watch videos of these sessions posted earlier on my website:

• FFS code review with Protesilaos
• FFS code review and Emacs extensibility with Protesilaos

Further, inspiration for parts of ffs's implementation was gratefully drawn from Protesilaos's Logos package for Emacs.

Dedicated to the loving memory of Farangis Yousefinia.

Below are the release notes.

I recently contributed a patch to tagref that makes it play nicely with Emacs org-mode files. The PR has already been merged and the feature is available since version 1.12.0.

In this post I want to explain what the PR improves and show how tagref can be used in a project where internal/developer documentation in written in org-mode. But first, let me briefly introduce tagref.

What is tagref?

tagref is a command-line tool that helps manage "tags" and "references" in a project. The idea is based on cross-referencing code and documentation, inspired by the GHC notes system described in the Glasgow Haskell Compiler (§5.6) chapter of the AOSA book.

In short, you can annotate code (or text in any file) with a tag inside a comment:

1
2
3
4
5

// [tag:rare-edge-case]
function handleRareEdgeCase() {
  ...
  ...
}

The tag can then be referenced elsewhere in the repository, such as a doc that explains why the particular edge case might happen or what the developer specifically needs to consider before changing that code.

1
2
3

### A rare edge case

[ref:rare-edge-case]

The same tag can be referenced in other files too. This way, different parts of code and docs become interconnected. When a developer comes across a ref they can quickly look up the tag, the associated notes as well as other references to get a holistic understanding of the code they are about to touch.

The tags and refs can be managed through a command-line interface provided by tagref to,

• list all tags and refs
• check that the referenced tags actually exist and that there are no duplicate tags
• list all unused tags

The check command can be run in a pre-commit hook or CI pipeline. This helps catch drift between code and docs, which is quite likely when internal documentation (architectural decision records, how-to guides, troubleshooting guides, checklists etc.) lives separately from the code.

Inside a monorepo (such as captrice's codebase), this kind of documentation and note-taking convention, along with the tagref tool, provides a decent system for annotating a source of truth (usually code, but sometimes a doc), and pointing back to it from other places in the repo. Markdown is probably the more popular format for such docs but I prefer to use org-mode, at least in my personal projects.

What did my PR solve?

Besides user defined tags, tagref also supports refs pointing to files and directories in the repository.

1
2
3
4
5
6
7

// Refer: [file:dev-docs/weekly-stats.org]
export async function computeWeeklyStats(
  db: IdbModel,
  now?: Date
): Promise<WeeklyStats> {
 ...
}

The above example is taken from captrice's codebase. The dev-docs/weekly-stats.org file documents optimizations and other decisions about calculating and displaying weekly stats on the home page.

The default sigil for file references is file: which happens to be exactly the same as the bracket-link syntax that org-mode uses for internal links. In org-mode, an internal link to another document can be added as,

1
2

* User home page components
  - [[file:./weekly-stats.org][Weekly stats]]

However, org-mode expects the file path to be relative to the current file, whereas tagref (prior to version 1.12.0) considers all paths to be relative to the working directory. I'd been working around this by specifying doc: as the custom file sigil, but there were limitations:

1. The --file-sigil option had to be explicitly specified every time tagref was run, otherwise the check would fail.

2. Despite having cross referencing between org files, tagref's check command couldn't be leveraged to catch broken links.

PR #273 addresses this by adding optional support for relative paths in file and directory references. If the path is prefixed with special path components such as ./, ../ and so on, it's considered relative to the file that contains the reference. Otherwise it's considered relative to the working directory (same as the original behavior, which makes the change fully backward compatible).

For example,

• [file:./weekly-stats.org] will be considered relative to the file in which it exists

• [file:weekly-stats.org] will be considered relative to the working directory

Preventing Emacs from normalizing relative paths

When editing org-mode files in Emacs, one almost never types out bracket links by hand. Instead, C-c C-l or M-x org-insert-link is used to insert a link interactively. But then the file path gets normalized i.e. even if ./doc.org is explicitly specified, it gets replaced with doc.org which is shorter and simpler representation of the same path.

This would cause tagref to treat it relative to the working directory. To prevent this, we can tell emacs to skip normalization of relative file paths. However, the solution feels inelegant as we're effectively patching a natively compiled core function file-relative-name in emacs, and not just an org-mode specific function. Considering this, we can conservatively define the advice such that it affects only those org buffers where the org-link-file-path-type variable is set to 'relative as a local binding.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

  ;; @HACK: When file-based link is added in an org file using the
  ;; bracket link syntax, we want a relative path in the same
  ;; directory to contain a `./' prefix if `org-link-file-path-type'
  ;; is set to `'relative'. This makes it work well with the `tagref'
  ;; tool. Without this advice, the path gets normalized
  ;; e.g. `./doc.md' becomes `doc.md' even when the former is
  ;; explicitly specified.
  ;;
  ;; This feels a bit hacky though because `file-relative-name' is a
  ;; core emacs function that we're patching and not an org-specific
  ;; one. Hence we're checking multiple pre-conditions to ensure that
  ;; the behavior takes effect only when required and can also be
  ;; opted out of.
  (advice-add 'file-relative-name
              :filter-return
              (lambda (path)
                (if (and (derived-mode-p 'org-mode)
                         ;; Only if set locally (e.g., .dir-locals.el)
                         (local-variable-p 'org-link-file-path-type)
                         (eq org-link-file-path-type 'relative)
                         (not (file-name-absolute-p path))
                         (not (string-prefix-p "." path)))
                    (concat "./" path)
                  path)))

To opt into this behavior, you need to override org-link-file-path-type locally for all files in the project. This can be conveniently done through a .dir-locals.el file at the repository root.

1
2
3

(
 (org-mode . ((org-link-file-path-type . relative)))
)

With these two pieces in place, tagref works seamlessly with org-mode files.

Charlie Holland has a very interesting post about annotation in place. The idea is to take notes on digital content the same way you would if your were marking up a book or a physical paper. The important thing is that you don’t want to suffer a context switch disruption by switching to another app to take your notes and you want those notes to appear (even years later) when you revisit the file. A secondary consideration is that you want to be able to go not only from the text to the notes but also from the notes to the text.

There is—as we Emacsers always say—an Emacs package for that. That package is org-remark. It does its magic just as you’d expect. The notes are anchored in the text by highlighting the passage you’re writing about and the position of that highlight and its associated notes are kept in a separate Org file with enough meta data to get back to the original document.

The package comes with builtin support for several document types but Holland says that it’s pretty easy to add others and that in fact he’s added them for Elfeed, PubMed, and Wombag. The major shortcoming that I can see is that PDFs aren’t supported.

Holland’s post includes an 18 minute, 15 second video that demonstrates org-remark and provides a nice overview of the post. The post itself is long and comprehensive.

The org-remark package seems like a nice app that could be a big help for those of us that like to take notes as we’re reading. I could see myself using it to take notes on Web pages that I want to write about for Irreal. If it seems like it might be useful to you, take a look at Holland’s post.

Update [2026-05-21 Thu 13:48]: Added link to Holland’s post.

I have added two new themes to the current development target of my ef-themes package. Screenshots are available below. Remember that the themes are highly customisable: you can change practically everything about them.

• ef-arcadia is a light theme with a verdant, humid aesthetic.
• ef-atlantis is a dark theme with an aquatic feel.

Both deliver the familiar colourfulness and good legibility of the ef-themes.

Always click to enlarge the image for best results.

ef-arcadia

ef-atlantis

Coming in version 2.2.0 (next stable release)

The character of each theme is well defined. I may still make some refinements.

Remember that since version 2.0.0, the ef-themes are built on top of my modus-themes. This means that they are highly customisable, support a wide range of packages and face groups, and are extensively tested down to the finest details.

Enjoy!

The ef-themes are a collection of light and dark themes for GNU Emacs that provide colourful (“pretty”) yet legible options for users who want something with a bit more flair than the modus-themes (also designed by me).

• Package name (GNU ELPA): ef-themes
• Official manual: https://protesilaos.com/emacs/ef-themes
• Change log: https://protesilaos.com/emacs/ef-themes-changelog
• Sample pictures: https://protesilaos.com/emacs/ef-themes-pictures
• Git repositories:
  • GitHub: https://github.com/protesilaos/ef-themes
  • GitLab: https://gitlab.com/protesilaos/ef-themes
• Backronym: Eclectic Fashion in Themes Hides Exaggerated Markings, Embellishments, and Sparkles.

This is my entry to the may 2026 emacs blog carnival hosted by Sacha Chua.

It is common knowledge that the default emacs keybindings can be a bit of a strain on the old hands. A common suggestion is to remap the caps lock key to act as control, and i did that for a while, but i don't think it's the perfect solution that is often suggested: stretching the pinky finger sideways and holding it down still results in pain after a while for me. Luckily i have the perfect solution with zero drawbacks: use your thumbs!

The first time i tried this was about five years ago. I put control on the key directly to the left of the space bar, and alt on the key directly to the right of the space bar. The thumb is very good at moving in this sideways motion, and i could immediately feel how much more comfortable my hands were with this layout. The trouble with this, though, is some keybindings using the thumb and fingers from a single hand still feel a little bit clumsy. Although the control and alt keys are in nicer positions, they still aren't perfect for all keybindings.

So i did the only sensible thing: i made the keys directly next to both edges of the space bar control, and the ones one key out alt. With this setup, i can use the left thumb for control or alt bindings using keys on the right side of the keyboard, and the right thumb for control or alt bindings on the left side.

Emacs is heavily based around keyboard shortcuts, so the benefits are immediately apparent. But as anyone who's ever used a mac will tell you, the command key is much more comfortable to use with all sorts of shortcuts than the control key is on windows or linux systems. You don't have to perform any sort of hand contortions, because your thumbs are almost already sitting on the modifier keys.

As i say, i've been doing this for about five years now, and i've never felt more comfortable typing. Setting this up is one of the first things i do when i reinstall my operating system, usually straight after i try to use a keyboard shortcut and realise it doesn't work because the modifier keys are in the original positions.

So if you're planning on trying out evil or something in order to make using emacs more comfortable, why not first try moving the modifiers around to see if those hench old thumbs or yours could alleviate some of the pain?

In my post on Omar Antolín Camarena’s May Emacs Carnival contribution explaining his reasons for using EWW as his default browser, I mentioned that Camarena said that one of the benefits of EWW not supporting JavaScript is that JavaScript is mostly used to make the user’s experience worse by doing things like loading ads, reconfiguring the user’s display parameters, and implementing paywalls.

If you had asked me, I would have said that any site using a paywall would also require JavaScript to load the content and, indeed, that’s true for some sites such as The New York Times but, as I discovered, it’s not true for a surprising number of sites.

After reading Camarena’s post, I decided to experiment a bit to see if it was possible to bypass paywalls simply by not running JavaScript. I mostly don’t care about paywalls because the majority of the sites that use them don’t have content that’s worth the effort of avoiding them. Still, I thought it would be interesting to test if the strategy was feasible.

I did this by opening any site that popped up a paywall in EWW. It worked for a surprising number of sites. Again, it’s almost never worth the effort but if you happen upon an article that you really want to read on a site that wants you to sign up for an outrageously expensive subscription, it may be worthwhile seeing if you can open it in EWW,

The other thing I learned is that reading content with EWW can be a very restful experience. No ads, no blinkenlights, and sometimes, no paywall either. I didn’t try running EWW with eww-readable but that would probably make the experience even more restful.

Last night I realized two things:

1. I haven’t touched Elfeed in about a month
2. I’ve been reading and interacting more with people’s posts than ever As I was looking at my Inkwell’s RSS feeds and cleaning up, I couldn’t help but notice how nice it looks:

And, yes, I prefer it over my list of feeds in elfeed, which are stored in an .org file - essentially lines of text with comments and tags.

I’m pretty sure this is the opposite case for most folks who use Emacs. First, Emacs users want to use Emacs more, not less, and second, Inkwell is not available without Micro.blog¹.

But I think this is the point I’m getting at: Inkwell belongs in Micro.blog; actually, it is Micro.blog.

When I started using Micro.blog three years ago, I considered it mostly an alternative to running my own static site with Hugo, between fixing issues with Hugo, my CSS, Netlify and understanding attempting to understand git and Magit. Yes, Micro.blog is an alternative to all of that, but it isn’t just a blogging platform; It’s a definition of a contemporary blogger.

If you look at Micro.blog’s set of tools, you’ll see what I mean: it contains tools to keep track and post about books, movies and TV shows, private (encrypted) notes, photos and self-made video clips², save articles and qoutes from around the internet (pocket style), automatic integration with other social media where possible - all of this around your hosted blog, complete with plugins and a theme (and let’s not forget the AI integration, if you want it and turn it on) you can tweak and take with you - your posts, media, css, everything - wherever you go.

And Inkwell adds an important direction to this mix.

My blogging hour in the morning now continues where I left off the night before, with saved highlights and complete articles from other people I keep track of. The integration between Inkwell and Micro.blog, where my reading turns into writing, still requires some work as the UI and some of the bugs get sorted out, but it’s there. And it’s already better and more intuitive for me than Elfeed, which takes place in its own isolated space.

Elfeed is very good at what it does (and hopefully, what it will keep on doing, with its creator leaving Emacs), and it has been good to me. It still is. But Inkwell, Micro.blog, and my recent adventures with finding out more bloggers and learning more about the Indieweb feel like an evolution. It’s the next step of whatever I’m doing here.

Footnotes

¹: I recall Manton borrowed the idea from a different RSS reader, but I can’t find the reference right now

²: Finding an alternative to YouTube these days is not easy, and if you’re not trying to “build a brand” and repeat the chant of “click and subscribe,” the only semi-reliable alternative that comes to mind is PeerTube and (maybe Dailymotion?) - but Manton found a way that seem sustainable, at least for now.

I think I’ll take my REPL neat
My parens black and my bed at three
CIDER’s too sweet for me…

– Bozier

Last week I announced Port, a small prepl client for Emacs. Today I’m following it up with another small Emacs package. Meet neat, a tiny, deliberately language-agnostic nREPL client.

Why?

For years I’ve been hearing some version of the same request: “could CIDER work with my non-Clojure nREPL server?”. Babashka, Basilisp, nREPL-CLR, even some homegrown servers people built on top of nREPL for languages I’d never heard of.¹ The answer was always the same kind of squishy “sort of, in theory, with caveats”, because while bare nREPL is genuinely language-agnostic, CIDER is not. CIDER was built for Clojure and assumes Clojure pretty much everywhere.

I always thought the right answer was “let’s gradually make CIDER more language-agnostic.” That’s the kind of plan that sounds reasonable until you actually try it.

The thing that pushed me over the edge was, oddly enough, building Port. Port is small, focused, and doesn’t try to be CIDER. Working on it for a couple of weeks reminded me how (deceptively) productive it is to start from a clean slate when the new requirements don’t match the assumptions baked into a mature codebase. Trying to retrofit CIDER into a language-agnostic shape would have meant fighting with every helper that ever assumed clojure.repl exists, every middleware contract cider-nrepl defines, every project-type heuristic that knows about deps.edn and project.clj and nothing else. A whole lot of “is the server Clojure, or is it the other thing?” branches. The Port experience reaffirmed that the right move for a genuinely different client is a new project, not a thousand cuts to an existing one.

So neat was born. The name is short, says what it does (it’s neat, both in the small-and-tidy sense and in the “no deps, no special assumptions, just the protocol” sense), and conveniently leaves room for puns I haven’t fully committed to yet. I might land on a backronym one day. For now it’s just “neat”.

What neat actually is

neat is a small Emacs nREPL client. The code is split across four files:

• neat-bencode.el: bencode encode/decode.
• neat-client.el: TCP connections, request dispatch, the standard nREPL ops.
• neat-repl.el: a comint-derived REPL buffer.
• neat.el: the entry point, customization group, and neat-mode minor mode for source buffers.

It only uses Emacs builtins. There are no external runtime dependencies, not even on clojure-mode, because neat doesn’t assume Clojure on the other end. If you write clojure-mode, fennel-mode, hy-mode, or anything else that talks nREPL, you turn on neat-mode in that buffer and it just works.

The connection routing is also intentionally library-friendly. There’s a buffer-local neat-current-connection override so downstream packages can implement their own routing logic, plus a global default for the simple “one server at a time” case that most people will want.

Capability discovery is done at connect time via the nREPL describe op. neat doesn’t hardcode “this server has completions, this one doesn’t” assumptions. If the server reports a completions op, the CAPF backend lights up (with type annotations next to each candidate, when the server provides them). If it reports lookup, eldoc starts working and M-. jumps to definitions via an xref backend. If neither is there, you still get a perfectly serviceable raw REPL.

Basic usage

Start an nREPL server. Anything that speaks the protocol will do. For a Clojure server:

1
2
3
4
5
clj -M:nrepl
# or
bb nrepl-server :port 7888
# or
lein repl :headless :port 7888

Then in Emacs:

1
M-x neat RET localhost RET 7888 RET

A REPL buffer pops up, the prompt follows the server’s reported namespace, and you can type expressions at it. Multi-line input works because RET only submits when the form parses as balanced under neat-repl-input-syntax-table (Emacs Lisp syntax by default, which is close enough for any Lisp). Input history is persisted across sessions.

If there’s a .nrepl-port file in the project, the prompt defaults to its contents, so M-x neat RET RET is enough to connect.

To evaluate from a source buffer, turn on the minor mode:

1
M-x neat-mode

The familiar bindings are there, intentionally compatible with what CIDER users expect:

neat-eval-buffer ships the buffer contents as an eval op; neat-load-buffer-file uses the standard load-file op instead, so the server can attribute file and line numbers to errors. Use the latter when you’re actually loading a file from disk and care about good diagnostics.

neat-set-ns sets the buffer-local neat-ns, which gets sent as the ns field on every eval op from that buffer. For languages where the namespace is declared in the source (Clojure’s (ns foo.bar), etc.), swap in a parser via neat-buffer-ns-function.

For juggling multiple connections, M-x neat-list-connections opens a tabulated-list buffer with one row per live connection, where you can set the default or disconnect interactively.

That’s roughly the whole user-facing surface today. There’s no jack-in command, no inspector, no debugger, no test runner. Likely there will never be, but if you need those you should probably be using CIDER anyways…

Should you use it?

If you write Clojure and CIDER works for you, keep using CIDER. It’s mature, full-featured, and supported, and I’m going to keep working on it for as long as people use it. Nothing about neat changes that.

But if you find yourself in one of these situations:

• you write a non-Clojure language whose runtime ships an nREPL server, and you’ve been muddling through with a half-supported CIDER setup,
• you write Clojure but you value minimalism and don’t need the full CIDER feature set,
• you’re building an Emacs package that needs to talk nREPL and you want a small, dependency-free library to build on,²

then neat might be a better fit. It’s small enough that you can read the whole thing in an afternoon, and the library/UI split (neat-bencode and neat-client are perfectly usable from other packages) is genuinely designed for downstream consumers.

The bigger picture

neat is part of a broader push I’ve been chewing on for a while now: making nREPL a healthy multi-language ecosystem rather than a Clojure-only protocol. That push has three legs:

1. An actual nREPL specification. The spec.nrepl.org draft is (will be) the formal version of what today is “whatever nREPL the project does”.
2. Reference clients. neat is one. The point of building a deliberately Clojure-free client is that it stress-tests the spec. Anywhere neat ends up needing to special-case the server, the spec has a gap.
3. A compatibility test suite. The parameterised integration suite in neat already runs the same assertions against multiple servers and surfaces real divergences (Clojure batching (println "hi") into a single out message where Basilisp emits two, for example). I’d like to grow this into a portable suite that any nREPL server can self-check against.

This is also why I keep teasing a “reference CLI client” in conversations. An editor client is one thing, but a small command-line nREPL client written in a non-Lisp language would be a much sharper test of how language-agnostic the protocol really is. neat is plausibly a precursor to that. Time will tell how far I push this; for now I just wanted to get the Emacs side moving.

Thanks

As always, big thanks to Clojurists Together and everyone supporting my open source work. You make it possible for me to keep tweaking and improving CIDER, nREPL, clj-refactor, and friends, and occasionally try something “neat” on the side. neat isn’t replacing any of the existing Clojure tooling for Emacs. It’s just another tool in the box for the people who want it.

Feedback, ideas, and contributions are most welcome over at the issue tracker.

Keep hacking!

Denote aims to be a simple-to-use, focused-in-scope, and effective note-taking and file-naming tool for Emacs.

Denote is based on the idea that files should follow a predictable and descriptive file-naming scheme. The file name must offer a clear indication of what the contents are about, without reference to any other metadata. Denote basically streamlines the creation of such files or file names while providing facilities to link between them (where those files are editable).

Denote’s file-naming scheme is not limited to “notes”. It can be used for all types of file, including those that are not editable in Emacs, such as videos. Naming files in a constistent way makes their filtering and retrieval considerably easier. Denote provides relevant facilities to rename files, regardless of file type.

• Package name (GNU ELPA): denote
• Official manual: https://protesilaos.com/emacs/denote
• Change log: https://protesilaos.com/emacs/denote-changelog
• Git repositories:
  • GitHub: https://github.com/protesilaos/denote
  • GitLab: https://gitlab.com/protesilaos/denote
• Video demo: https://protesilaos.com/codelog/2022-06-18-denote-demo/
• Backronyms: Denote Everything Neatly; Omit The Excesses. Don’t Ever Note Only The Epiphenomenal.

Below are the release notes.

Version 4.2.0 on 2026-05-20

This version brings several improvements to the core denote package as well as all the Denote extensions I maintain. The core package is stable, its feature set is rich, and the wider ecosystem of extensions is growing.

Most of the changes documented herein are of interest to experienced users who may be looking for ways to refine their workflow. I recommend that new users start with the basics, as I explained them in the original video demonstration of Denote or as they are documented in the manual’s section for newcomers:

• Webpage: https://protesilaos.com/emacs/denote#h:c54bedb4-5377-4dbd-853c-5870ace6eb33.
• Info manual: With the latest denote package installed, evaluate (info "(denote) Getting started with Denote").

Remember that the release notes are true only at the time of publication. The single source of truth is the official manual.

Core Denote

Overview of the new features

• The command denote-dired-focus will filter the results of an existing denote-dired buffer. Use this to narrow down the results.

• In Org files, the denote: link type can now be previewed using the built-in org-link-preview command, starting with Org version 9.8.0.

• The command denote-link-or-create-with-command extends the existing convenience functions of the “do or create note” kind.

• The denote-file-prompt uses completion metadata to sort by most recently accessed, group by directory or file extension, and cover packages that display cosmetic icons alongside completion candidates.

• Denote now enforces a controlled vocabulary for keywords when denote-infer-keywords is set to nil, such that only the denote-known-keywords are provided as an option at the relevant prompts.

• The mechanism for integrating Denote with org-capture now supports prompting for an signature via denote-org-capture-with-prompts (the signature is an optional, free-form component of the Denote file-naming scheme).

• Several packages that extend Denote are documented in the manual. If you have a package for Denote, let me know and I will write a section about it.

Focus a denote-dired buffer with denote-dired-focus

The command denote-dired produces a Dired listing of file names that match the given regular expressions. Users can benefit from the Denote file-naming scheme to, for example, include all files that have the keyword _emacs. In the resulting Dired buffer, the new command denote-dired-focus can then be invoked to further narrow down the results, such as to only show files that have 2026 in their file (with default settings, the date is part of the Denote identifier).

I implemented this feature in response to issue 693 by 82Kang: https://github.com/protesilaos/denote/issues/693.

Improvements to the file prompt

Various Denote commands prompt for a file name: for instance, denote-link asks which file to link to. This file prompt is now augmented with completion metadata that transform how files look and how the information is organised.

Before, the prompt presented full file names like:

20220610T043241--initial-thoughts-on-the-zettelkasten-method__notetaking.org
20220610T062201--define-custom-org-hyperlink-type__denote_emacs_package.md
20220610T162327--on-hierarchy-and-taxis__notetaking_philosophy.txt

Those same file names are now transformed to look like this:

2022-06-10  initial-thoughts-on-the-zettelkasten-method  notetaking
2022-06-10  define-custom-org-hyperlink-type  denote_emacs_package
2022-06-10  on-hierarchy-and-taxis  notetaking_philosophy

The files will be grouped by file extension or directory (if they are in a subdirectory of the denote-directory). Furthermore, they will be sorted by most recently accessed.

The underlying file names are still available except that their presentation is modified. This means that input at the minibuffer prompt will still match everything they contain.

This completion metadata extends to the packages all-the-icons and nerd-icons, which are now instructed to add the correct file icons to the completion candidates: an Org file will have the unicorn icon beside it, for example.

Users who do not like the new style can revert to the plain presentation by setting denote-file-prompt-extra-metadata to nil.

Advanced users who wish to set up the completion-category-overrides may target the denote-file completion category or, anyhow, modify the denote-file-prompt-extra-metadata.

Link to a file or create a new note using a specific command

Denote provides many “convenience wrapper” commands that do something quickly which can also be achieved with minimal configuration. For example, the denote command may be modified to also prompt for a file type and so the denote-type command is like denote with the addition of the file type prompt. Users can look at the source code of denote-type to write their own small variations (the manual provides several examples as well).

The denote-open-or-create-with-command may then use those to implement its specified behaviour of “open an existing file or create it using a convenience wrapper command”.

Same principle for the new denote-link-or-create-with-command: it makes possible the workflow of “link to an existing file or create a new note with the given command”.

Convenience wrappers are listed in the value of the user option denote-commands-for-new-notes.

Thanks to Matthew Batson for building on top of existing functionality to contribute denote-link-or-create-with-command in pull request 674: https://github.com/protesilaos/denote/pull/674. Matthew has assigned copyright to the Free Software Foundation.

Preview denote: links in Org files

Starting with Org version 9.8.0 custom link types such as denote: can implement their own preview mechanism. In practice, this means that denote: links pointing to image files will now work as expected with org-link-preview (remember that the Denote file-naming scheme can be applied to any file and is in no way specific to note-taking—I use it for documents and videos, for example).

Thanks to Samuel W. Flint for the original contribution in pull request 683: https://github.com/protesilaos/denote/pull/683, with further changes by me. The original contribution is small, meaning that Samuel does not need to assign copyright to the Free Software Foundation.

Signature support in Org capture

The denote-org-capture-with-prompts function now supports the signature file name component as an additional parameter. This function is meant to be used in tandem with the org-capture mechanism, as shown in the manual.

Thanks to Tobias Lidman-Strauss for the contribution in merge request 2 on the GitLab mirror: https://gitlab.com/protesilaos/denote/-/merge_requests/2. The change is small, meaning that Tobias does not need to assign copyright to the Free Software Foundation.

The denote-fontify-links-mode is only relevant for .txt files

The denote: links are automatically highlighted as links in Org and Markdown bufers. Users who prefer to write notes in plain .txt files must enable the denote-fontify-links-mode to get the same effect.

I have revised denote-fontify-links-mode to only work with .txt as its other users were not necessary. In the process, I have deprecated the denote-fontify-links-mode-maybe function: just use the denote-fonftify-links-mode.

The keys RET and C-c C-o open the link (same keys used by Org and Markdown modes).

Growing ecosystem of Denote packages

In the Denote manual I mention packages that build on top of Denote. There is one section for each package. The manual now includes the following:

• denote-agenda (by Samuel W. Flint): Use Denote notes as Org agenda files.
• denote-journal-capture (by Samuel W. Flint): Enhanced journaling workflows.
• denote-lint (Peter Smith): Checks for inconsistencies in Denote file names and front matter.
• denote-project-notes (by Samuel W. Flint): Integrate Denote with Emacs’ built-in project support.
• denote-regexp (by Samuel W. Flint): Search and link notes using regular expressions.
• denote-review (by Matto Fransen): A package for reviewing notes over time.
• denote-sections (by Samuel W. Flint): Manage sections within Denote notes.
• denote-wordcloud (by Alexander Kuzmin): Generate word clouds from Denote notes.

Miscellaneous

• The command denote-dired (alias denote-sort-dired) is refactored to work as intended in all cases. Thanks to kilesduli for the contribution in pull request 666: https://github.com/protesilaos/denote/pull/666. Further changes by me, including the option to maintain many separate denote-dired buffers, which I did in response to issue 693 by 82Kang: https://github.com/protesilaos/denote/issues/693.

• I have revised the denote-grep mechanism and all of its ancillary functions and variables are revised in the interest of consistency and maintainability. Thanks to gnuhack for contributing a macro that was meant to streamline some commands. This was done in pull request 697: https://github.com/protesilaos/denote/pull/697. I eventually changed lots of things so that the macro was not relevant anymore, though mine was a change with a wider scope.

• The Org link storage mechanism (denote-link-ol-store) now works correctly within org-capture buffers, allowing for more flexible linking workflows.

• Following non-Denote Markdown links no longer result in an error under certain circumstances. Thanks to bplubell for the contribution in pull request 685: https://github.com/protesilaos/denote/pull/685. The change is small, meaning that its author does not need to assign copyright to the Free Software Foundation.

• Retrieving front matter is now more reliable, even when the buffer is unsaved. Thanks to kilesduli for the contribution in pull request 672: https://github.com/protesilaos/denote/pull/672. Also thanks to Jean-Philippe Gagné Guay for reviewing the change and for reporting a problem with an earlier version of the code in issue 670: https://github.com/protesilaos/denote/issues/670. Further changes by me.

• The various Denote rename commands that affect the front matter in files no longer change existing spacing. I did this to address the comment posted by Morten Kjeldgaard in issue 703: https://github.com/protesilaos/denote/issues/703.

• Updated the documentation to explain how to automatically encrypt new notes when using a custom file type.

• Refined the internal helper functions for directory management and identifier validation.

• Thanks to nescias for fixing three typos in the manual. This was sent to me as a patch, which I installed as commit c772378.

Changes to the extensions of Denote I maintain

This is about packages I maintain. Some of them were originally part of the denote.git repository, but I moved them out into their own packages to make everything easier to reason about.

consult-denote version 0.5.0

• Package name (GNU ELPA): consult-denote
• Official manual: https://protesilaos.com/emacs/consult-denote
• Change log: https://protesilaos.com/emacs/consult-denote-changelog
• Git repository: https://github.com/protesilaos/consult-denote

• Backronym: Consult-Orchestrated Navigation and Selection of Unambiguous Targets…denote.

• References to the long-obsolete “denote-silo-extras-” prefix are replaced by “denote-silo-”. Thanks to IT Ascalium for the contribution in pull request 20: https://github.com/protesilaos/consult-denote/pull/20. The change is small, so its author does not need to assign copyright to the Free Software Foundation.

• The consult-denote-file-prompt correctly handles relative file paths when denote-directory is set to a list of directories. This is what the underlying denote-file-prompt does (which I mentioned above about its metadata). Thanks to Kai von Fintel for the contribution in pull request 24: https://github.com/protesilaos/consult-denote/pull/24. The change does not require copyright assignment.

denote-merge version 0.1.0

• Git repository: https://github.com/protesilaos/denote-merge
• Official manual: https://protesilaos.com/emacs/denote-merge
• Backronym: Denote… Merging Eventually Reformats the Given Entries.

This is an optional extension to the denote package. It provides commands and relevant user options to streamline the work of merging contents from one Denote file to another. This is for users who periodically review their notes to add, remove, or otherwise consolidate their accumulated knowledge.

denote-journal version 0.3.0

• Package name (GNU ELPA): denote-journal
• Official manual: https://protesilaos.com/emacs/denote-journal
• Git repository: https://github.com/protesilaos/denote-journal

• Backronym: Denote… Journaling Obviously Utilises Reasonableness Notwithstanding Affectionate Longing.

• The user option denote-journal-keyword now supports a nil value, allowing users to create journal entries without a specific keyword. Thanks to nescias for sending me the patch via email, which I installed as commit d4cc501 in denote-journal.git. The change does not require copyright assignment.

• Fixed an issue about how the function denote-directory-files was used. Thanks to Donald Brady for reporting the bug in issue 656 on the main Denote repository and to kamchy for confirming the problem: https://github.com/protesilaos/denote/issues/656. The approach was utlimately revised in denote.git courtesy of a change by Jean-Philippe Gagné Guay in pull request 661: https://github.com/protesilaos/denote/pull/661.

denote-markdown version 0.3.0

• Package name (GNU ELPA): denote-markdown
• Official manual: https://protesilaos.com/emacs/denote-markdown
• Git repository: https://github.com/protesilaos/denote-markdown

• Backronyms: Denote… Markdown’s Ambitious Reimplimentations Knowingly Dilute Obvious Widespread Norms; Denote… Markup Agnosticism Requires Knowhow to Do Only What’s Necessary.

• The package defines a markdown-obsidian file type which can be used by relevant note-creating commands, such as denote or the convenience wrapper denote-type. This file type is updated to be more robust, in accordance with some changes in core Denote (I am not even documenting those, as they are not intended for users).

denote-org version 0.3.0

• Package name (GNU ELPA): denote-org
• Official manual: https://protesilaos.com/emacs/denote-org
• Git repository: https://github.com/protesilaos/denote-org

• Backronym: Denote… Ordinarily Restricts Gyrations.

• The command denote-org-link-to-heading now supports linking to the current file when called with a prefix argument. This way, a file can have links between its headings. Thanks to Tonus for pointing out that it was impossible to create a link inside the current file. This was done in issue 17: https://github.com/protesilaos/denote-org/issues/17.

• A helper function for retrieving the backlinks of a heading is updated to return full file paths. Thanks to Vedang Manerikar for the contribution in pull request 20: https://github.com/protesilaos/denote-org/pull/20. Vedang has assigned copyright to the Free Software Foundation.

• Another helper function is updated to conform with changes to core Denote with regard to how the denote-link-description-format is handled. Thanks to Jung Han for reporting the bug in issue 21: https://github.com/protesilaos/denote-org/issues/21.

denote-silo version 0.3.0

• Package name (GNU ELPA): denote-silo
• Official manual: https://protesilaos.com/emacs/denote-silo
• Git repository: https://github.com/protesilaos/denote-silo
• Backronym: Denote… Silos Insulate Localised Objects.

The minibuffer prompt for silo directories uses the corrent completion category (consistent with what I mentioned above about completion metadata). Thanks to Wilf-bog for reporting an error with the completion prompt in issue 1: https://github.com/protesilaos/denote-silo/issues/1.

denote-sequence version 0.3.0

• Package name (GNU ELPA): denote-sequence
• Official manual: https://protesilaos.com/emacs/denote-sequence
• Git repository: https://github.com/protesilaos/denote-sequence
• Backronym: Denote… Sequences Efficiently Queue Unsorted Entries Notwithstanding Curation Efforts.

This package deserved its own release notes, as I did a lot of work on it. But as this file is already long, I will focus on the essentials:

• The denote-sequence-scheme used to support a numeric and alphanumeric option. There now is a third one called alphanumeric-delimited. It combines features from the other two and may be better suited for especially long/intricate sequences.

• The denote-sequence-reparent command now works recursively to produce the desired consequences to all descendants of a given sequence note. Thanks to Peter Prevos for the contribution in pull request 13, which further changes by me: https://github.com/protesilaos/denote-sequence/pull/13.

• The command denote-sequence-view-hierarchy produces a bespoke buffer with all the sequence notes that form a hierarchy. The buffer displays file titles, the concomitant sequence, and file keywords. Each level of depth is expressed by a number of spaces, controlled by the user option denote-sequence-hierarchy-indentation. In the hierarchy buffer, there are commands that move to the next/previous item, or forward/backward at the same level of depth. RET opens the file at point, TAB folds/unfolds the tree. The user option denote-sequence-hierarchy-move-and-open controls whether motion commands should automatically open the file, which by default happens in the other window (users who modify the variable denote-open-link-function will get the specified behaviour in this context as well). The denote-sequence-view-hierarchy can be called with one or two prefix arguments to limit to a given sequence prefix and/or level of depth (something that denote-sequence-dired also supports). In short, this is a way to visualise your sequence notes in a buffer that has a different presentation than Dired.

• Thanks to alan-w-255 for renaming and refining a prompt that is also used in the hierarchy feature. This was done in pull request 15: https://github.com/protesilaos/denote-sequence/pull/15. The change is small, meaning that its author does not need to assign copyright to the Free Software Foundation. Further refinements by me.

• Thanks to Nicolas Semrau for binding q to quit-window in the denote-sequence-hierarchy-mode-map. This was done in pull request 20: https://github.com/protesilaos/denote-sequence/pull/20. The change is small, meaning that Nicolas does not need to assign copyright to the Free Software Foundation.

• The denote-sequence-file-prompt-extra-metadata is the functional equivalent of the aforementioned denote-file-prompt-extra-metadata.

• Thanks to liyingzhi for pointing out an inaccurate comment in the docstring of denote-sequence-scheme. This was done in issue 18: https://github.com/protesilaos/denote-sequence/issues/18.

• The denote-sequence-dired is updated to align with the modalities of denote-dired, as noted above. Thanks to juh for reminding me about the need for changes in issue 14: https://github.com/protesilaos/denote-sequence/issues/14.

• Thanks to Stefan Monnier for pointing out a stylistic mistake in an older version of denote-sequence-dired. This was done on the emacs-devel mailing list: https://lists.gnu.org/archive/html/emacs-devel/2025-11/msg01119.html. Also thanks to Stefan for telling me about some other compiler warnings: https://lists.gnu.org/archive/html/emacs-devel/2025-11/msg01119.html.

Git commits

~/Git/Projects/denote $ git shortlog 4.1.0..4.2.0 --summary --numbered
   184	Protesilaos
     4	duli
     3	Jean-Philippe Gagné Guay
     3	Matthew Batson
     2	alvmts
     2	gnuhack
     1	Alvin Hsu
     1	Matto Fransen
     1	Samuel W. Flint
     1	Tobias Lidman-Strauss
     1	bplubell
     1	gvalson
     1	nescias

Pretty much every project that I actively maintain on my GitHub account has a change log of some description. For a long time now, whenever I add a new entry to the log, I'll include a link to the PR that implements that change. Inevitably, this results in me adding the ChangeLog entry, creating the PR, then doing a follow-up change and commit now that I know the PR number, which allows me to add the link.

So I've created next-gh-pr.el to save me just a little time and let me be just a little more lazy. Inside it I've currently got a next-gh-pr-insert-markdown-link command which, when run, as you might imagine, inserts a link to the next likely PR URL as Markdown.

Working out the next URL is simple enough: get the latest issue and PR number, take whichever is the highest, and add 1. There is the wrinkle that discussions also cause this number to bump, and getting the latest discussion number is a little extra faff that I can't be bothered with right now, but my projects very seldom have discussions taking place anyway.

Marcin Borkowski (mbork) really likes all the ways you can mark files in Dired but noticed that an easy way to mark recently modified files was missing. He knows quite a bit about writing Elisp so it was an easy decision to decide to write some code to implement the missing feature.

The code, which you can see at his post, is pretty simple and easy to follow. What wasn’t so easy were some annoying design decisions. For example, what constitutes the current day? Is it 24 hours ago until now or is it the previous midnight until now? And by the way, should that be UTC or local time?

The natural interface is to specify the number of previous days you want to mark as a prefix argument but that leaves open the question of how to unmark the last n days. The natural solution—and the one mbork chose—is to use a negative n to mean “unmark the last n days”. So positive n, mark files modified in the last n days; negative n unmark file modified in the last n days. What about 0? Mbork made the arbitrary decision to have that mean mark files modified in the last 60 minutes.

There are a couple of other nuances that you can read about in mbork’s post. The real takeaway for me is how tricky it can be to get the small details right. That seems especially true when you’re dealing with time calculations. Questions like, “What, exactly, does ‘yesterday’ mean” turn out to be a lot harder to answer than they first seem. Take a look at mbork’s post to see what I mean.

I haven't been very active on this blog for the last few months. I've recently started a new job, and part of what I've been doing in my spare time is adding to my Emacs configuration to make some of the daily chores easier (or to remove them entirely).

If you know me, you know I'm not a fan of WebUIs, or just mouse-focused GUIs in general. Jira is no exception. Previously, I've had to deal with Jira's annoying click and drag nonsense and sort of dealt with it, but I've always wanted to be able to use it from within Emacs. Not just because that means no mouse-based WebUI, but also because it potentially means making custom automations around tickets. Enter the new job, where I'm able to make myself an API token, and therefore make use of org-jira for the first time.

You can see the config I've written around it here. This works basically exactly as expected, although I have had to do something a bit hacky to keep the API token properly stored. Storing the key on MacOS as recommended in the readme wasn't working for me, so instead I've stored it as a generic password. When launching Jira, this password is fetched into the kill ring to be pasted into the prompt if needed. This is kind of terrible, but it does work well enough.

(when (equal system-type 'darwin)
  (kill-new
   (string-trim-right (shell-command-to-string (concat "security find-generic-password -a \""
                                                     jiralib-user "\" -s \"jira\" -w")))))

You should be careful when storing the API token with add-generic-password, make sure you write it in the command with -w "<token>" and don't copy it into the prompt. When I was copying it into the prompt, the token was getting cut off, which was a pain to debug because Jira cloud doesn't have 401 errors for this sort of thing on the JQL search. You may also notice string-trim-right here: the output of shell-command-to-string includes the trailing newline, which will mess up the auth.

I'm also using my org projects space as the Jira workspace locally, which means I can use all the same organisation helpers as I do with my personal project files.

In terms of automations, org-jira already provides useful enough keybinds for progressing tickets, leaving comments, etc., and at the moment I don't feel like I need to improve there. However, since this Jira instance is integrated with Bitbucket, it's convention to use the ticket number when opening a new branch for work related to that ticket. That way Jira can show things like PR status, etc.

Because each Jira board or project only has one repository associated, I'm assuming that there will be only one directory for that project work, and that can be a customizable variable.

(defcustom jira-key-directory-alist '()
  "Directories associated with a particular project --- git repositories.
For example, (\"CBM\" . \"~/build/etc\") will use ~/build/etc for ticket-specific commands in the CBM project."
  :type 'alist
  :group 'jira
  :group 'theurgy)

Then this simple function fetches the Jira issue ID under the cursor, opens a magit status buffer in the appropriate directory, and starts branch creation.

(defun jira-branch-ticket ()
  "Create a branch from the current ticket, in the repository specified by `jira-key-directory-alist'."
  (interactive)
  (let* ((issue-key (progn
                    (org-jira-copy-current-issue-key)
                    (substring-no-properties (car kill-ring))))
       (project-code (car (split-string
                           issue-key
                           "-")))
       (project-dir (cdr (assoc project-code jira-key-directory-alist))))
    (magit-status project-dir)
    (kill-new issue-key)
    (call-interactively #'magit-branch-create)))

I'm not pre-selecting main/master as the origin here because it's possible that I may want to branch off something else. Nor am I pre-populating the branch name, just killing the ticket number, in case I need multiple branches per ticket.

Ideally, I would like to pre-populate the magit branch prompt with some editable default values, but I'm not actually sure how to do that, so this will do for now.

The next blog will look at the AWS CLI customisations I've built up, so stay tuned.

Of all the built-in editing commands in Emacs, the commands that work with rectangles delight me the most. Once understood, they can save effort in many situations.

That said, the biggest downside to rectangles is the amount of setup it takes to use them. As with many things Emacs, by default you have to memorize a bunch of keybindings to get anything done with them.

In Casual, I addressed the above downside by providing a Transient menu for rectangle commands. Since building that, I've come to use rectangle commands routinely. But even then, there is ceremony to set up a rectangle selection.

With my recent work on mouse-driven interactions in Anju, I’ve learned that rectangle selection is trivial via C-M-<mouse-1> dragging. Once selected, having a menu of rectangle commands makes working with them even easier. So I made one for the latest v1.4.0 update for Anju, now on MELPA.

The “Rectangle” sub-menu is available via the main menu bar “Edit” menu (as shown in the screenshot above) or via context menu. Using rectangle commands in conjunction with the align-regexp (“Edit › Align Regexp…”) and whitespace-cleanup (“Edit › Delete › Whitespace Cleanup”) can make short work of editing text that is laid out in columns. Anju makes both of these commands available from the main menu.

Side note: on using C-M-<mouse-1>, sometimes Emacs will only read M-<mouse-1> and do a secondary selection, leaving an unwanted highlight. Enter M-<mouse-1> to dismiss the highlight.

If you find Anju to be useful, please support its development by buying me a coffee. I’ve got a number of new features planned for it.

I have been a VC-mode loyalist for years, it is built in, it is simple, it covers the basics - commit, push, pull, diff, all there with C-x v bindings. I never really felt the need for Magit, honestly. VC-mode just works, right?

Until it does not. Or rather, until you need something that is not quite available. As vc-mode is source code control agnostic then there were always going to be some limitations and my git usage is now starting to become a little more advanced.

Recently I hit a divergent branch situation, remote had moved on, I had local commits, and git refused to push, I reached for C-x v m (vc-merge) to pull in the upstream changes, and that worked fine as a merge. But what if I wanted a rebase instead? Clean linear history, no merge commits?

Turns out there is no vc-rebase at all in Emacs! You can use vc-pull and it will rebase if pull.rebase is set in your git config (I think, although I haven't tried it), but there is no interactive vc-rebase command to invoke directly. And vc-merge only merges, If you want a rebase, you have to drop to shell or configure git to default to it. I wanted something more cohesive, more discoverable, and #sigh, here enters magit, I used it a few years ago so I still had a residue of muscle memory, but that said, I am not abandoning VC-mode entirely. For quick operations, a single file commit, a blame, a quick diff – C-x v I still like vc-mode. Magit is great for repo-level operations; VC-mode is great for file-level ones. They complement each other nicely, and there is no reason to pick one over the other, this is Emacs!

I added use-package magit to my config with a C-x g binding, full-frame status display, word-granular diff refining, and also released C-w in the magit status map so my window-management prefix still works (small things, but they matter):

(use-package magit
  :bind ("C-x g" . magit-status)
  :config
  (setq magit-display-buffer-function
        #'magit-display-buffer-same-window-except-diff-v1)
  (setq magit-refresh-status-buffer t)
  (setq magit-section-initial-visibility-alist
        '((untracked . show)
          (stashes . hide)))
  (setq magit-diff-refine-hunk 'all)
  (define-key magit-status-mode-map (kbd "C-w") nil))

I see a lot of blog posts recommending EWW. Sometimes I even write about them. The common theme is something along the lines of, “No, you can’t really replace a full-fledged browser with EWW but you can do a lot and a ”real“ browser is only a keystroke away.”

In another May Emacs Carnival entry, Omar Antolín Camarena offers his reasons for using EWW. He agrees with the conventional wisdom that EWW isn’t a replacement for a normal browser but that it is useful in many situations and even has some advantages over your default buffer.

He believes that one of the chief advantages of EWW is that it doesn’t run JavaScript. That’s ironic, of course, because EWW’s lack of support for JavaScript is one of its most oft cited shortcomings. But Camarena says that lack is often an advantage because JavaScript is often used to load ads or a paywall or to reconfigure your display preferences often choosing low contrast colors that are hard for anyone but the young to read.

His second reason for using EWW is that it brings the power of Emacs to your Web browsing. Among the advantages he lists are:

• You can easily resize images without changing font and other sizes.
• You can read the Web site content in multiple columns using follow-mode.
• You can use occur for a search and keep a list of results and easily navigate among them.
• You can evaluate ELISP directly in the EWW buffer and many other language as well with a bit of plumbing.
• You can use eww-readable to eliminate a lot of the junk that comes with many Web pages.

And, as Camarena stresses, you can always escape to a normal buffer with eww-browse-with-external-browser, bound to & by default.

Before we discuss Rewrite Bun in Rust, there is something that needs to be said—because no one else is saying it.

Bun stands where it does today because of Zig.

Jarred chose Zig back then not because it was "cool," but because Zig enabled a small team to rapidly prototype a high-performance JS runtime without a garbage collector or a heavy runtime. Zig's low friction, direct memory manipulation, and straightforward C interop were the core reasons Bun could punch above its weight on performance with an extremely small team in its early days. The architecture, data structures, and low-level design of Bun as it exists today were shaped by Zig.