Categories: community

RSS - Atom - Subscribe via email

Thinking about Emacs coaching goals with Prot

| emacs, community

: Hooray for learning out loud! Prot has already posted his responses.

Following up on Emacs Carnival March 2026: Mistakes and learning to reach out: I want to get better at learning with other people's help, so I'm going to experiment with engaging Prot as an Emacs coach. Our first session is this week. Time to lay the groundwork!

If I meet with Prot twice a month for three months, that's a budget of €60 (~CAD 100), which is a reasonable size for an experiment especially since I still have the budget set aside from the Google Open Source Peer Bonus and lovely folks already donated to cover the costs for EmacsConf. When I schedule something with someone, the accountability makes it easier to get stuff done and out the door. For this, a real person is much better than AI because:

  • I get to take advantage of Prot's very large context window, and he knows stuff about the Emacs, the community, and me that I might not remember to mention
  • He can ask real questions and prod at things that are unclear or contradictory, unlike the confirmation bias of LLMs
  • He might point out things that wouldn't occur to me to ask about
  • It triggers my "I promised someone I'd do this" thing
  • I get to support an individual worth supporting rather than contributing to the concentration of wealth and information in for-profit entities

My motivations:

  • I want to make better use of my focused time during the rest of the schoolyear. For the next three months, my schedule will be fairly predictable and I'll have regular chunks of focused time. Over the past two months, I've averaged around 10 hours of Emacs-related stuff per week (including 1.5 hours or so for Emacs News). I'm currently thinking about language learning and speech input. EmacsConf is on the horizon and will probably ramp up after September, but I can also think ahead of workflow improvements or ways to collaborate with other people. I might put together an Emacs News Highlights presentation. Also, I'm always looking out for ways to build the community.

    Summer break during July and August will shake things up again, but I might be able to find some focused time early morning or evening. I'd like to be in a good position to make the most of those time fragments.

  • I want to improve my Emacs Lisp development workflow and learn more about libraries and techniques that might be useful. I'm beginning to have more time to sharpen the saw and I'm curious about all the cool stuff that I missed or skimmed over the past ten years. What are some useful setups for completion, debugging, navigation, etc.?
    • Current: I sporadically use the extra awesomeness in seq, pcase, lispy, erefactor, ert, buttercup, and undercover, but not consistently. I'd like to reduce the friction and make these habitual.
    • Areas of friction / improvement:
      • writing tests, especially for things that are more interactive
      • navigating code that might be scattered in literate config files or in Emacs Lisp files
      • forgetting to restart or to make sure all code is saved; running tests via Emacs batch mode will help, as will package-isolate and restart-emacs
  • I want to improve my workflows for writing, making videos, and streaming. If I get better at sharing what I'm working on, I might be able to connect with more people and bounce ideas around. Also, accountability might help me nudge this over the threshold. I probably still need to work in stops and starts, so I want to reduce the friction. I'm curious about other people's workflows for sharing. I like joining meetups, but I tend to share stuff only if no one else has anything planned, because I have my blog and my YouTube channel in case I want to share anything with a wider group of people. I just have to actually post things.
    • Current: ~1.5 Emacs posts a week aside from Emacs News, attending meetups, sporadically adding short video demos to posts

      Average number of Emacs-related posts that aren't Emacs News
      (let* ((start "2026-02-01")
             (end "2026-03-31")
             (posts (my-blog-posts
                     start end
                     (lambda (o)
                       (and (member "emacs" (alist-get 'categories o))
                            (not (member "emacs-news" (alist-get 'categories o)))))))
             (count (length posts)))
        (my-weekly-average count start end))
      
    • Goal: 2-3 non-News posts a week, one video a month, one stream or meetup a month; maybe also beyond looking at the numbers, it might be interesting to build more momentum around a topic, set up trails/navigation, cultivate more of a digital garden
    • Areas of friction / improvement:
      • Resisting "one more tweak"
      • Streaming: Still need to get the hang of talking to myself or having half-conversations with chat: can be worked around by scheduling a session with Prot and opening it to the public
      • Hiding private information or setting up a separate Emacs for demonstration
      • Harvesting videos/clips/notes afterwards
  • I want to move more of my configuration into files and libraries that other people can reuse, like sachac/learn-lang and sachac/speech-input. I can also separate the function definitions from the configuration in my code so that people can reuse the functions if they want.
    • Areas of friction / improvement
      • renaming things when I want to move them to a library
      • duplicating small functions (ex: simplify string)
      • figuring out how to make it possible for someone else to start using my stuff

Starting questions for Prot:

  • Meta: what are people finding useful for coaching and behaviour change, like learning new keyboard shortcuts or workflows?
  • Your literate config exports to individual .el files. I could probably do something similar to separate my functions from my personal config in order to make it easier for people to reuse parts of my config. Is it worth doing so? Do people tell you that they use those private Emacs Lisp files by loading them, or do they mostly rely on your published packages?
  • Does the division into multiple .el files work fine if you need to bisect your configuration?
  • Do you have some tweaks to make it easier to jump to function definitions considering a literate configuration?
  • What's your general process for migrating things from your config to a repository or package?

Could be fun. Let's experiment!

View Org source for this post

Emacs Carnival March 2026: Mistakes and learning to reach out

| community, emacs

Mostly-similar versions follow: I started with French, translated it to English, and then tweaked some details. Thanks to Philip Kaludercic for hosting this month's carnival!

In English

The theme for this month's Emacs Carnival is Mistakes and Misconceptions. It’s difficult to pinpoint one thing that is clearly a mistake, but there are certainly things I could do more effectively.

My configuration is very large because I assume my little modifications are only useful to me. They feel too specific, too idiosyncratic. I think people who create libraries or even packages used by lots of other people are awesome. I don't know if I could quite do that myself, though! Even submitting patches upstream and participating in the ensuing discussions sometimes requires more persistence than I have.

The advantage of keeping my changes in my config is that even if I'm unsure, I can try something out, develop a rough prototype, and change my mind if necessary. When I publish them in a library or a package, I feel like I have to polish my ideas. It's hard to stick to just one idea long enough to refine it.

My favorite situation is when I write about my attempt in a post, and it inspires someone else to implement their own version (or even a new library or package). On the other hand, if I learn to share my code, I can help more people, and I can also learn from more people and more conversations.

Many of my modifications are short and easy to copy from my posts, but there are a few collections that depend on other functions, making them difficult to copy. These functions are scattered across several posts on my blog. For example, my functions for learning a language (I'm learning French at the moment) and for controlling Emacs by voice are becoming quite complex. The functions are also exported to my configuration, but the Emacs Lisp file is difficult to navigate if someone wants to copy them. I can extract the code into a file now that Org Mode can tangle to multiple files, but if I spend a little time replacing the "my-" prefix with a library prefix and move them to a repository, people could clone it and download updates. Even if no one uses it, the act of polishing and documenting it will probably be useful to me one day.

So, it's possible that this is a mistake I often make in Emacs: thinking my functions are too idiosyncratic and too rough, so I leave them in my config. If I dedicate time to extracting the code into a library, I might benefit in the long run. I know lots of people are interested in using Emacs for language learning or by voice. There have been so many other libraries and workflows over the years, so I'm sure people are out there. I want to practice learning more with others. To start, I can make sure interested people can follow my progress through RSS feeds or Mastodon, I can respond when people send me messages, and I can collect contact info and send them a message when I post about the subject.

I can write more if I reread the changes in my configuration each week, or if I reread my complete configuration for sections which I haven't yet written about. If I participate in virtual meetups or even livestream, I can find out what interests other people. If I submit patches and create tasks in my Org Mode inbox to track the discussions, I can practice refining my work.

Prot has lowered his coaching prices to €10 /hour. He's quite prolific when it comes to package development, so he can probably help me figure out how to get stuff out of my config and into a form that other people might be able to use. I've been enjoying learning with my French tutor. It might be worth experimenting with spending some money and time to improve my Emacs skills as well. Sure, it's totally just for fun, but I think it's valuable to practice learning with the help of others instead of stumbling around on my own.

There's always more to learn, which is wonderful. So this is not really a mistake, just something that could be good to work on. Onward and upward!

Check out Emacs Carnival March 2026: Mistakes and Misconceptions to see other people's takes on the topic.

En français

Le thème du Carnaval d'Emacs ce mois-ci est « les erreurs et les idées reçues ». C'est difficile d'identifier une chose qui soit clairement une erreur, mais il y a certainement des choses que je ne fais pas efficacement.

Ma configuration est très volumineuse car je pense que mes petites modifications ne sont utiles que pour moi. Elles sont trop spécifiques, trop particulières. J'apprécie ceux qui créent des bibliothèques ou même des paquets que beaucoup d'autres utilisent, mais de mon côté, je ne me sens pas capable de le faire pour l'instant. Même soumettre des correctifs en amont et participer à la discussion qui s'ensuit parfois demande plus de persévérance que je n'en ai.

L'avantage de garder mes modifications dans ma configuration est que, même si je ne suis pas sûre, je peux essayer quelque chose, développer un prototype préliminaire, et changer d'avis si nécessaire. Quand je les publie dans une bibliothèque ou un paquet, j'ai l'impression que je dois peaufiner mes idées. C'est difficile de s'en tenir à une seule idée assez longtemps.

Ma situation préférée est quand je partage mes essais sur mon blog, et qu'ils inspirent une autre personne qui implémentera sa propre version, voire une nouvelle bibliothèque ou un nouveau paquet.

En revanche, si j'apprends à partager mon code, je peux aider plus de personnes, et je peux aussi apprendre de plus de personnes et de plus de conversations.

Beaucoup de mes modifications sont brèves et faciles à copier de mes articles, mais il y a quelques collections qui dépendent d'autres fonctions, ce qui les rend difficiles à copier. Les fonctions sont dispersées dans plusieurs articles sur mon blog. Par exemple, mes fonctions pour apprendre une langue (particulièrement le français) et pour contrôler Emacs par commande vocale deviennent plutôt complexes. Elles sont aussi exportées vers ma configuration, mais le fichier Emacs Lisp est difficile à parcourir si on veut les copier. Je peux extraire le code dans un fichier maintenant que Org Mode peut le tangler vers plusieurs fichiers, mais si je consacre un peu de temps à remplacer le préfixe « my- » par celui de la bibliothèque et à le pousser sur le dépôt, les gens pourraient le cloner et récupérer les mises à jour. Même si personne ne l'utilise, le fait de les peaufiner et de le documenter me sera utile un jour.

Donc il est possible que ce soit une erreur que je commets souvent dans Emacs : je pense que mes fonctions sont trop idiosyncratiques et trop brutes, je les laisse donc dans ma configuration. Mais si je consacre du temps à extraire le code vers une bibliothèque, j'en bénéficierai peut-être à long terme. Je sais que beaucoup de gens sont intéressés par l'utilisation d'Emacs pour apprendre une langue ou pour la commande vocale. Il y a eu de nombreuses autres bibliothèques et flux de travail au fil des ans, donc je suis sûre qu'il y a du monde. Je veux m'entraîner à apprendre auprès de plus de personnes. Pour commencer, je peux m'assurer que les gens intéressés peuvent suivre mon progrès via les flux RSS ou sur Mastodon, je peux répondre quand on m'envoie des messages, et je peux recueillir les coordonnées et leur envoyer un message lorsque je publie un article à ce sujet.

Je peux écrire davantage si je relis les modifications dans ma configuration chaque semaine, ou si je relis ma configuration entière pour les sections dont je n'ai pas encore parlé. Si je participe à des réunions virtuelles ou même si je diffuse en direct, je vais voir ce qui intéresse les autres. Si je soumets des correctifs et crée des tâches dans ma boîte de réception Org Mode pour suivre les discussions, je m'entraîne à affiner mon travail.

Prot a baissé ses tarifs de coaching à 10 euros de l'heure. Il est très prolifique en matière de développement de paquets. J'apprends bien avec mon tuteur en français, donc cela vaut peut-être la peine de consacrer de l'argent et du temps à améliorer mes compétences sur Emacs. Certes, c'est juste pour le plaisir, mais c'est aussi important pour moi de m'entraîner à apprendre avec l'aide des autres au lieu de trébucher toute seule.

J'ai toujours plus de choses à apprendre, ce qui est merveilleux. Ce n'est pas vraiment une erreur, mais plutôt un point à améliorer. En avant !

Consultez Emacs Carnival March 2026: Mistakes and Misconceptions pour d'autres perspectives sur le sujet.

View Org source for this post

Emacs elevator pitch: tinkerers unite

| emacs, community

This is for the Emacs Carnival 2025-08: Your Elevator Pitch for Emacs hosted by Jeremy Friesen. Emacs is a text editor, but people have made it so much more.

Text and links from sketch

Emacs elevator pitch https://sach.ac/2025-08-31-01

That's the theme for the August Emacs Carnival.

I don't spend much time in elevators these days, and I didn't talk much to strangers even during the before-times.

So let's imagine this is more of, say, a meetup. (Someday I'll get back to going to those.) Could be tech, could be something else. Could be online, could be in person.

I don't have to convince everyone. I don't even have to convince a single person. My goal is to listen for the tinkerers: the ones who like to ask "Why?" and "What if?" and who try things out. They're interesting.

I can find them by:

  • watching talks (sketchnotes are a great thank-you gift)
  • eavesdropping or asking questions
  • sharing what I'm tinkering with

No: Why would anyone do that? Yes: Have you thought of trying xyz?

For tinkerers, the juice might be worth the squeeze. Emacs can be challenging, but it can also pay off. It can even be fun.

Even when I find a fellow tinkerer, the conversation isn't "Have you tried Emacs? You should try Emacs." It'll probably be more like:

"I'd love to keep hearing about your experiments. Do you have something I can subscribe to or follow?" (Side-quest: Try to convince them to blog.)

and then the conversation can unfold over time:

  • "Ooh, I like that idea. Here's my take on it."
  • "How did you do that? What's that?!"
  • "Oh, yeah, Emacs. It's very programmable, so I can get it to do all sorts of stuff for me. Wanna see?"

…and sometimes they fall into the rabbit hole themselves, as tinkerers often do. But even if they don't try Emacs (or don't stick with it), cross-pollination is great. And sometimes Emacs changes their life.

To get a sense of the kinds of things someone has gotten Emacs to do, check out Alvaro Ramirez's post. I have a list like that at emacs. On the topic of cross-pollination, I like Jeremy Friesen's EmacsConf 2023 talk on Mentoring VS-Coders as an Emacsian (or How to show not tell people about the wonders of Emacs).

It's always fun to come across a fellow tinkerer. I love seeing what people come up with. Emacs works out really well for tinkerers. It's not just about taking advantage of the technical capabilities (and you can do a surprising amount with text, images, and interaction), it's also about being part of a great community that's in it long-term. Good stuff.

Feel free to use this sketch under the Creative Commons Attribution License.

View org source for this post

Working on the plumbing in a small web community

| community, connecting, emacs, blogging

The IndieWeb Carnival prompt for May is small web communities. I've been exploring some thoughts on how a little effort goes a long way to connecting a community. Sometimes I think of it as working on the plumbing so that ideas can flow more smoothly. It feels a little different from the direct contribution of knowledge or ideas. I also want to connect with other people who do this kind of thing.

Emacs is a text editor that has been around since the 1970s. It's highly programmable, so people have come up with all sorts of ways to modify it to do what they want. It's not just for programmers. My favourite examples include novelists and bakers and musicians who use Emacs in unexpected ways. Because Emacs is so flexible, community is important. The source code and documentation don't show all the possible workflows. As people figure things out by themselves and together, more possibilities open up.

I love tweaking Emacs to help me with different things I want to do, and I love learning about how other people use it too. I've been sharing my notes on Emacs on this blog since 2001 or so. In 2015, as I was getting ready to become a parent, I knew I was going to have much less time and focused attention, which meant less time playing with Emacs. Fortunately, around that time, John Wiegley (who was one of the maintainers of Emacs at the time) suggested that it would be helpful if I could keep an eye on community updates and summarize them. This worked well with the fragmentation of my time, since I could still speed-read updates and roughly categorize them.

Text from sketch

Community plumbing

You don't have to fill the pipes all by yourself. Just help things flow.

I want to share some of the things we're doing in the Emacs community so that I can convince you that building plumbing for your community can be fun, easy, and awesome. This is great because enthusiasm spreads.

virtuous cycle

  • Other places: YouTube, Reddit, HN, lobste.rs, Mastodon, PeerTube, mailing lists….
  • Blog aggregator
    • Planet Emacs Life (uses Planet Venus) - update: [2025-05-31 Sat] I wrote my own RSS feed aggregator instead.
  • Newsletter: Emacs News, 1-2 hours a week
    • summarize & group
    • announce calendar events
  • User groups
    • [often use Emacs News to get conversations going]
  • iCal & Org files: Emacs Calendar
  • Conference
    • EmacsConf: < USD 50 hosting costs + donated server + volunteer time

Tips:

  • Make it fun for yourself.
  • Build processes and tools.
  • Let people help

2024-01-31-05

Some more notes on the regular flows built up by this kind of community plumbing:

Daily: Lots of people post on reddit.com/r/emacs and on Mastodon with the #emacs hashtag. I also aggregate Emacs-related blog posts at planet.emacslife.com, taking over from planet.emacsen.org when Tess had DNS issues. There are a number of active channels on YouTube and occasionally some on PeerTube instances as well. I don't need to do much work to keep this flowing, just occasionally adding feeds to the aggregator for planet.emacslife.com.

Weekly: I collect posts from different sources, remove duplicates, combine links talking about the same thing, categorize the links, put them roughly in order, and post Emacs News to a website, an RSS feed, and a mailing list. This takes me maybe 1.5 hours each week. It's one of the highlights of my week. I get to learn about all sorts of cool things.

Weekly seems like a good rhythm for me considering how active the Emacs community is. Daily would be too much time. Monthly would lead to either too long of a post or too much lost in curation, and the conversations would be delayed.

Sometimes I feel a twinge of envy when I check out other people's newsletter posts with commentary or screenshots or synthesis. (So cool!) But hey, I'm still here posting Emacs News after almost ten years, so that's something. =) A long list of categorized links fits the time I've got and the way my mind works, and other people can put their own spin on things.

Monthly: There are a number of Emacs user groups, both virtual and in-person. Quite a few of them use Emacs News to get the discussion rolling or fill in gaps in conversation, which is wonderful.

Some meetups use meet.jit.si, Zoom, or Google Meet, but some are more comfortable on a self-hosted service using free software. I help by running a BigBlueButton web conferencing server that I can now automatically scale up and down on a schedule, so the base cost is about 60 USD/year. Scaling it up for each meetup costs about USD 0.43 for a 6-hour span. It's pretty automated now, which is good because I tend to forget things that are scheduled for specific dates. My schedule still hasn't settled down enough for me to host meetups, but I like to drop by once in a while.

Yearly: EmacsConf is the one big project I like to work on. It's completely online. It's more of a friendly get-together than a formal conference. I have fun trying to fit as many proposed talks as possible into the schedule. We nudge speakers to send us recorded presentations of 5-20 minutes (sometimes longer), although they can share live if they want to. A number of volunteers help us caption the videos. Each presentation is followed by Q&A over web conference, text chat, and/or collaborative document. Other volunteers handle checking in speakers and hosting the Q&A sessions.

It's a lot of fun for surprisingly little money. For the two-day conference itself, the website hosting cost for EmacsConf 2024 was about USD 56 and our setup was able to handle 400 viewers online (107 max simultaneous users in various web conferences).

EmacsConf takes more time. For me, it's about 1.5 hours a day for 4 months, but I think mostly that's because I have so much fun figuring out how to automate things and because I help with the captions. Lots of other people put time into preparing presentations, hosting Q&A, participating, etc. It's worth it, though.

I like doing this because it's a great excuse to nudge people to get cool stuff out of their head and into something they can share with other people, and it helps people connect with other people who are interested in the same things. Some Q&A sessions have run for hours and turned into ongoing collaborations. I like turning videos into captions and searchable text because I still don't have the time/patience to actually watch videos, so it's nice to be able to search. And it's wonderful gathering lots of people into the same virtual room and seeing the kind of enthusiasm and energy they share.

So yeah, community plumbing turns out to be pretty enjoyable. If this resonates with you, maybe you might want to see if your small web community could use a blog aggregator or a newsletter. Doesn't have to be anything fancy. You could start with a list of interesting links you've come across. I'm curious about what other people do in their communities to get ideas flowing!

Related: the community plumbing section of my blog post / livestream braindump.

View org source for this post

Lispy Gopher Show 2025-02-05: programming languages, history, blogging, and communities with screwtape, Ramin Honary, and me

| community

I joined @screwtape's Lispy Gopher Show at the last minute because he wanted to chat a little about community, his experiences starting a new blog, and my recent post Through blogging, we discover our thoughts and other people. Ramin Honary was also there, so the conversation also included Scheme, CL, Haskell, and other cool things. I shared the notes I was taking (yay screen mirroring!) and occasionally jumped in. Halfway through, I decided to experiment with adding timestamps to my notes. MP3 from the archive. (Ooh, someday I should embed the audio and then have the hyperlinks skip to sections or highlight in sync…)

Text and links from sketch

Lispy Gopher Show with screwtape, Ramin Honary, and me (Sacha Chua)

2025-02-05

Next steps/recommendations:

  • Blog! Share notes & links

Not-entirely-sorted topics:

  • DeepSeek
  • energy
  • climate
  • lower consumption
  • Kent, Emacs variants
  • Gypsum
  • Scheme
  • Yale
  • Haskell
  • Ramin Honary
  • drawing notes during conversation
    • memory
  • mastodon
  • monads
  • Lambdas + procedures
  • Haskell
  • also other things aside from chained side effects
    • 0:30 T, Jonathan Rees
  • Community
    • frustrating communication
      • diversity of perspectives
    • brainstorm
    • Disconnects?
    • 0:48 silos?-porting.
    • crossovers, listening to others
    • Medium?
      • 0:33 ghost stories?
        • punchlines
      • history
        • 0:40 Python, CMUCL, history
        • ooh, community stories
    • Substack?
    • Bumping into things, serendipity
    • network
    • AI?
    • flow of info
  • recursion
  • 0:41 Haskell
  • 0:35 Dijkstra anecdotes
  • people are very opinionated
  • 0:43 CL - Haskell, typechecking
  • 0:47 Lambda calculi
  • Kenichi Sasagawa
    • life trajectory: accounting, SICP
      • intuition
    • IS Lisp, Prolog
      • islisp.info
  • 0:44 The Curse of Lisp
    • solo coders vs. cooperating
    • I can do it myself
  • intuition

Sketch ID 2025-02-04-05

I might find it interesting to dig a little more into the community topics. Curious about how other Lispy communities do things, considering that Lisp Curse essay that has turned up twice now in our conversations. Hmm…

View org source for this post