00:00:08 Warming up
[Sacha]: All right. Hello, this is Yay Emacs 24, I think. And today I'm going to be talking to Prot, who is going to join eventually. In about five minutes is our scheduled time. And I want to pick his brain about newcomers, the newcomer experience for Emacs, the starter kits, what we can do to make it easier for people to get into Emacs, and how we can support lifelong learning. So let me spend a few minutes here getting all set up so that if you have any questions, you can use the YouTube chat during the live stream so that I can read your questions out loud to Prot. And also so that I can share everything. I think my audio is working. And also in the meantime, I can tell you what I've been doing lately. I have just posted a guide to newcomers presets, which is a new feature in Emacs 31. It's a theme that enables a bunch of defaults. Sorry, that changes a bunch of defaults to make it a little bit nicer for people. And let's see, what was that? I don't know what that sound just meant. Okay, Prot, it says he's in the Google Meet room. So I will now admit him. And I think we should be live. Fantastic. Hello. Hello, hello. All right. [Prot]: Hello, Sacha. Good day. [Sacha]: Hello, Prot. Good day. Thank you for joining early. I was just doing my pre-session panicking and warming up. But since you're here and since I have a hard stop in about one hour, a little over one hour since I have to make the kid a grilled cheese sandwich, let's dive right into it. [Prot]: Yes, yes. The grilled sandwich cannot wait. [Sacha]: No, no, no. She'll be hungry. So, the theme for the Emacs Carnival this month was newbies and starter kits. And it gives us a good excuse to start thinking about How do we make the Emacs experience better for new users? Now I know you probably have run into a lot of new users from the talks that you've been giving, the packages you make, everything, the coaching. So tell me about what you've been thinking about this so far. 00:02:36 C-g is supposed to get you out of everything, but it doesn't work for the minibuffer
[Prot]: Yeah, yeah, yeah. So broadly speaking, there are a few pain points that I think every new user experiences. One is the behavior of C-g. The fact that you have the mini buffer open and you do C-g because C-g is supposed to get you out of where you are and the mini buffer will stay open by default. And I have seen people struggle live. It's like, oh, I am, you know, they have the mini buffer open, they click somewhere else, then they type C-g, the mini buffer stays there, and they're like, what is happening? Why is this not working? It stopped working. That's the one thing. 00:03:11 Anything related to display-buffer is hard for people to configure. Many windows do not focus by default. You have to switch to the other window to q.
[Prot]: not just beginners, struggle with is anything related to display buffers, which can be configured, of course, via the display-buffer-alist. And some of the common pain points with that are the fact that many windows do not focus by default. For example, you open a helper buffer, it doesn't focus the window by default. So if you want to type q to dismiss it, you have to switch to it, then type q. You do a care, it doesn't focus a care by default. You have to go there and then interact with it. These sorts of things. And then there are a few other things. I have written some settings that I can share with you as well. Maybe I can, I don't know, email them to you and then you can... I don't hear you now. One second. [Sacha]: Sorry, I turned on mute. Do you want to share your screen? Because that's another thing you can do. [Prot]: Yes, of course, of course, of course. But I meant to say that, so I have this here, and I was of course about to write a blog post and all that. Let me increase the font size. Is this font size okay or is it too small? [Sacha]: Oh, this is good. Yeah, yeah, yeah. [Prot]: Okay, so I have written a few things, so I don't have to go through all of them. 00:04:28 Good defaults
[Prot]: based on what I have noticed. 00:04:35 How do I set my fonts? Which is the one I should be using?
[Prot]: how do I actually set my fonts, right? Because there are like a million ways to do this as well. And the people are like, okay, but which is the one that I should be using? And of course, when I pick one option, I don't mean to say that this is the right option, but it's just to not be technical about it. Like, okay, just use this and forget about it. A few other settings and a few common packages. And at the end of this... Oh, sorry. I have to really make this point. 00:05:13 ediff is unusable by default for everyone, not just newcomers
[Prot]: Out of the box, Ediff is literally unusable. I cannot excuse that. Everything else I can excuse, this is not excusable. Sorry. This is the minimum viable setup for it. [Sacha]: So maybe that's something to suggest for newcomer presets or maybe even the defaults. [Prot]: I would say the defaults. This is not a newcomer thing. Basically, if you want to have that default layout, you just have to opt into it. Sorry if I'm offending anyone, but I don't mean to say that. You have to consider the ergonomics of it. 00:05:52 Packages to install
[Prot]: some packages, third party packages. that I recommend for installation. This is not exhaustive. I try to be minimalist here. So, of course, there are many, many good, excellent, top-notch packages that I don't recommend here. And, for example, I don't recommend any of my packages here. But I just included some for people to get started. [Sacha]: So it sounds like we should have a Prot starter kit. [Prot]: No, no. I already have too many packages that I maintain. 00:06:28 People muddle through, but it's confusing
[Sacha]: It also sounds like you are talking to a lot of newbies and you are hearing about a lot of pain points and frustrations. How are people finding information in the first place? How are people finding this information? Do people tell you about their experience of getting into Emacs? Where are they finding the stuff? How do they find their way to you? [Prot]: Generally they muddle through. So they will find a blog post, they will find a video, they will just do some search. Now, of course, there is also LLMs providing feedback. So it's a combination of all those and they try to piece together whatever kind of knowledge those sources provide. The thing with the newcomer experience is that there isn't a curation of content. Like of course you were doing that thing with the wiki, right? So of course you are working towards that. But what I mean is there are like options like, oh, you can do it in these 10 different ways. But for a newcomer, this is just details that don't make sense. Because the newcomer cannot weigh the pros and cons of each option, or even if they have pros and cons, or they are just different ways of expressing the same intent. Such as with the fonts, for example. You can do the frame fonts, or the faces, or whatever. [Sacha]: Okay, so if there was something more curated, what would that look like? I know you spend a lot of time thinking about the, you know, the information architecture of your documentation, which is the lovely thing about your pack, one of the many lovely things about your packages. But what could that kind of newcomer experience look like for documentation? 00:08:20 The wiki might be a good approach for the community. Start here.
[Prot]: What you were doing with the wiki, I think is the right approach from a community perspective, meaning like, yeah, here is the single point of entry. Take it from there. Basically, don't look elsewhere. Start with this. No matter what you do, start with this. I think that's a good approach and basically in the community we should be agreeing on that. I didn't see all of your videos yesterday. I don't have the time to watch all of it. But basically on the Emacs subreddit, which is basically where a lot of people find information. That's the first thing that should be on the sidebar or basically it could even be pinned on the on the top of the tips and tricks section, the thread there. So that's the one thing. Yes, please. [Sacha]: Yes, so the Emacs subreddit does have in its sidebar a link to the Emacs Wiki. Not calling out the Emacs Newbie page specifically, but there is a page. There's a link to the Emacs Newbie page from the Emacs Wiki homepage, I think. But yeah, as long as we can come up with a reasonably coherent starting point for people, then that will inevitably show up in people's recommendations as they respond to all these threads. [Prot]: Yes, yes, very well, very well. 00:09:33 The direction of the newcomers theme is nice
[Prot]: the direction of the newcomers theme. I don't know exactly now if newcomers theme works in practice. Like, I don't know what happens if you do Emacs disable-heme, or specifically what I mean.
[Prot]: but what I mean if you do this: mapc disable-theme right, the custom enabled theme maybe you have seen this right so you want to disable all the other themes before loading your theme right I'm sure somebody has written something like this maybe I have done it and then it's like you know load your favorite theme now right and then you do your favorite theme or whatever For example, here. So in this case, I don't know what happens to the newcomers theme. I will assume that it will disable it. In which case, I think that has to be prevented. [Sacha]: Oh, but then it wouldn't be treated the same as other things. [Prot]: Which you can do. Which you can do, for example, if I go to Fontaine. And of course, I got this from use-package. But you can do it with a synthetic theme. So there is a little trick you can do. 00:10:45 Themes versus minor modes
[Sacha]: I was looking at newcomers presets recently, and when I was trying to make instructions for people to actually use this stuff, I ended up leaning towards just telling them to use either the splash screen, of course, or M-x customize-themes, from where they can check and uncheck things if they wanted additional themes layered on top of that. It's not like you can't uncheck it and then all of your settings go back to what they were before. Some of the things are still left over. [Prot]: That's why I like the direction. I'm not sure if it should be a theme though. I think it should be a minor mode. And the minor mode should be like here is the opinionated settings and here are the default settings. [Sacha]: Do we already have like a mechanism for letting minor modes override the variables in a nice way but let you go back to the previous version? Because it's not just restoring the default customized ones either. [Prot]: I do something like that in Logos but I'm not sure to be honest right now how I even do it. Set arg and maybe this was a wrong time ago so I cannot even recall what exactly I was doing but actually this was contributed by Daniel Mendler so of course something like this could be added to Core Emacs as part of the newcomers theme eventually. If not, somewhere in core anyway. 00:12:19 People think of themes as styles, not arbitrary customizations
[Prot]: Basically, I like the idea, I don't think it's the right tool. Because themes are... It's also confusing language, you know? Because theme, when you talk to the average person, they will think of the style. And they won't think about arbitrary customizations. Whereas in Emacs we have this idiosyncratic conception of theme where it's like any kind of a user option as well as faces. [Sacha]: So it sounds like if it were a package that defined a minor mode that people could turn on and off Even better, yes, exactly. [Prot]: And there is this user option. I forget, do I even have it here for the built-in packages? I don't remember if I added it here. No, there is something like update the built-in packages. Yeah, so there is an option like that. So, of course, it could be like built into Emacs 31 as well as ELPA, kind of like Eglot. And then users could be like, okay, update this. So going forward, they can also benefit from whatever comes from Emacs 31. Or, you know, the development target of Emacs going forward. 00:13:55 Listing changes for newcomers-presets
[Sacha]: One of the challenges that I encountered when I was starting to play around with newcomers presets or other things like that is that it turns on all these options, but there's no easy way for people to say, okay, this is what has changed. This is how to use it. So I've started documenting that. And I think this is a challenge generally for many of the starter kits. It takes already a lot of work to make the configuration and maybe answer people's questions or It's a tricky situation how best to do it. [Prot]: I guess the natural place for that is the manual. And the manual, I believe right now the manual mentions something along the lines of, well, newcomers can just toggle this on kind of thing, but it doesn't really tell them what that will entail. So I think it's worth actually keeping track of all the changes and be like, well, the newcomers theme will change this and that and the other. And it could just be a bullet point of items. Maybe it doesn't have to go into all the technicalities like, hey, we are changing, I don't know, the isearch so that it shows the counter. By default, it doesn't show the counter, right? Like, it doesn't need to be as detailed. It can just say, okay, these are the user options that are affected. [Sacha]: or the minor modes that are enabled. You know, the specific commands and variable settings, whatever. It's like, how do I combine these different concepts to do something? Or taking a step back further, something we've talked about in previous conversations, how do I even begin to learn this overwhelming number of concepts? You know, how do I start to memorize all these keyboard shortcuts? And I'm not sure we have a lot of support for that yet. 00:16:10 Terminology is also a challenge
[Prot]: No, because I think part of the challenge here is the terminology. For example, if we say completion like me and you and other users, we kind of know what we are talking about, right? So minibuffer and orderless and all that, right? But if the user wants to express something along the lines, they may say the search box. Or, you know, like the interaction panel or whatever. So they don't have a language of the completion framework or the mini buffer or whatever. So even then it can be tricky for them to kind of narrow down what they are searching for. 00:16:52 Maybe documentation aliases?
[Prot]: to also think in terms of clusters of configuration, kind of what starter kits do with the various modules they define. And you can have aliases for them. Aliases in the manual, I mean. Like in the manual, if you type i, it goes to the index, right? And you can have a concept index. So you can have a concept index for the search panel or whatever. And that means the minibuffer and friends. [Sacha]: So it's like we're doing search engine optimization so that people can find things with the words that they use. I'm not sure that will be in the Emacs manual itself, but one of the things I've appreciated about people sharing their notes through blog posts and things like that is because they're using their words to describe a concept, and they're linking it to the code that uses the words that Emacs does. So then people can then say, oh, I'm looking for this. It's actually called this in the Emacs world. But this takes time for people to kind of make those connections. 00:17:56 Learning Emacs as a nonprogrammer
[Sacha]: if you can look back to like 2019 when you were learning all of this stuff for the first time? What was it like for you as a non-programmer to come into this world where people are using all these strange terms? [Prot]: Yeah, it was a challenge for sure. But I think actually the fact that I started out as a beginner, as a beginner into programming, I mean, benefited me in the sense that I was a blank slate. I don't have to unlearn terms. So I didn't have a concept of, okay, in other, I don't know, programming IDEs, for example, they call this the narrowing framework or whatever. I was like, completion. Okay, let's move on. It was the first time I was introduced to such concepts. So I think in that sense, I was lucky. That granted, there is a lot of reading involved. I was reading the manual and learning from it. [Sacha]: And that's something I do too. I mean, I'll still casually flip through the Emacs manual or the Org manual because every time you read it, there's something else that catches your eye and makes you think, how do I use that? How do I do that? And I like that, you know, you and Mickey Peterson and other people have also been organizing these thoughts into like a linear arrangement of logical progression. So that's the books that There aren't a lot of books about Emacs that people can read. 00:19:29 Emacs Lisp Elements
[Sacha]: your Emacs Lisp elements? How do we support their learning journey from, I have absolutely no idea how to do anything in Emacs to, okay, I'm ready to read this book and get stuff out of it? [Prot]: Yeah, yeah. When I recommend that book, I recommend it to people who have already decided that Emacs is the right tool for them. So I would basically say, look, Elisp is for you if you are already sold on Emacs, because what Elisp gives you is that extra you need to make Emacs do what you want, basically to tap into the potential programmability of Emacs. But to get to that point, you have already been convinced that you already like Emacs. If you don't vibe with it at the outset, you won't learn Elisp, not least because it's a niche language. 00:20:28 Getting the hang of Emacs
[Sacha]: Okay, so how do we get people to the point where they can vibe with Emacs? Where they can appreciate it? Because when they start off, it's this clunky text editor that has these weird keyboard shortcuts and strange terms, and all we can do is offer them videos and blog posts from people who say, this is totally awesome. I've been using it for three years or 20 years or whatever, and I love it. That's the light at the end of the tunnel, but there's a lot of tunnel to get through. [Prot]: correct correct correct it's difficult and i think that's why something like the newcomers theme ultimately is the way forward where it's like yeah opt into this and that's already a good set of defaults and i think what really matters is to reach a point where you can actually open your files actually move around and that happens with the very basics like that happens with the tutorial already what the tutorial doesn't give you is the basic interface, such as the mini-buffer. The default mini-buffer, I don't think it's good for beginners. Actually, maybe it's not even good for advanced users, but that's another. You have to have a few of the basic packages enabled, and then the tutorial, I think, is enough for that initial push. Then, of course, it's also up to the user to do some reading, based on what you will provide them with. [Sacha]: I know when I was trying this, I started a fresh Emacs so that I could see what it's like when people don't have their accumulated cruft of 20 years of configuration. And I was like, I need some kind of completion that I don't have to keep pressing tab for. So maybe Fido vertical mode can be part of that, you know, standard, at least in ?? or whatever, that would be nice. But yeah, there are a lot of these niceties that reduce the friction enough that people can then start enjoying things more and more. 00:22:28 Getting help when you have a starter kit
[Sacha]: They're great at getting people over that initial hump. But the challenge with starter kits and probably things like the newcomers presets has also been that when people ask for help, it's hard because they don't know the things that have changed under the hood. So they're asking for help and the people who are helping them are like, I don't know what's going on there. [Prot]: More so if the starter kit has its own macros and way of doing things, such as Doom Emacs. On the one hand, Doom Emacs does an excellent job at integrating everything, providing a polished experience, comprehensive configuration and so on. On the other hand, they have their own way of doing things like they have their own macros. You have to use Doom sync or whatever to do things from the command line. So somebody who is not using Doom basically has no means of knowing what is happening in that world. So that is definitely a challenge. So for me, a good starter kit is one that at the very least uses what a generic configuration would use, meaning no macros, no weird shell scripts and that sort of thing. [Sacha]: And I did spend some time going over the starter kit list in the Emacs wiki to try to sort it by minimalist, stays close to vanilla, all the way to the changes a lot of things about Emacs and you probably should ask the community of that starter kit first if you need help. So that's kind of like Doom Emacs and Spacemacs at that end of the spectrum and things like better defaults would be like at the Like just a little bit of smoothing over of things. But then also, it was interesting to see some of the starter kits focus on saying, okay, you don't have to write any code to extend this further. A lot of the things are available through Customize. 00:24:25 Customize is overwhelming for beginners
[Sacha]: for a newcomer. So how do we get people to the point where they might feel comfortable going through this Customize interface And saying, oh, I can find what I want to change and I can change it and I'm not worried about breaking everything. [Prot]: Yeah, I actually, when I was trying to use Customize with people, I gave it an honest try. Like, for example, we tried to do Emacs Customize the org capture templates. And I was seeing it live. Impossible for people to understand what is happening. Like, Customize has this concept of the insert button, right? So if you have a list of things, you can do insert to add the next element to the list. If you have an Elisp understanding of what you are actually interacting with, you kind of know what to do, right? But otherwise, I was seeing it live. It's like... I have no idea what is happening. What is this? So for me, my approach is basically skip customize altogether. For me, it's a lost cause. Unless it's completely rewritten, I mean in its current form, it's not good for beginners unless it's for toggles, like true or false kind of thing. If it's for anything more involved, it's not good. And what it is good for is for discovery, discovery of user options. But it presents the user options in a human-readable format which you cannot just copy-paste into your configuration. So, for example, it doesn't have the dashes for the names. [Sacha]: Yeah, and getting it out of the customized variables if you wanted to keep a nice clean Emacs is hard. Although I would say that's more of an intermediate level concern. When they start caring about having a beautiful Emacs that other people can learn from. A couple of comments in from people who are watching the stream. Hello, folks! Hello! @hajovonta6300 says, "Hi legends." @JacksonScholberg and @petertillemans2231 say, well, @JacksonScholberg says hi. @petertillemans2231 says, "I am not worthy." @takoverflow says, "Thank you for these streams." @ShaeErisson says, "I love Emacs but haven't really learned Elisp." And I know Shae has been using Emacs for a long time. So that's interesting that you have people who enjoy using Emacs. I don't know whether something is getting in their way when it comes to learning Emacs Lisp or whether it's just totally fine already the way it is. So that's different things. @JacksonScholberg says, oh, so @hajovonta6300 says, "you are worthy if you are willing to learn." Maybe the resources are there as people start digging into EmacsLisp. Maybe the combination of looking at other people's source code and trying to ask on Reddit or whatever is enough. @JacksonScholberg says," I vibe with Emacs after using other text editors that were not minimalist enough for my preferences, plus having experience with other open source software like Linux." @petertillemans2231 says, "Well, Emacs and minimalist in the same sentence. Strange concept, but I know what you mean." There's a whole spectrum of things you can do with Emacs, right? So yeah, people can just use basic Emacs. 00:27:53 debug-init
[Sacha]: "I guess learn starters quickly to use emacs --debug-init. Maybe not in the first hour, but close to it. Close to tweaking. [Prot]: Yeah. Which of course doesn't help. It's very useful, of course, but it doesn't help beginners because they cannot read the backtrace. [Sacha]: Yeah, it is hard to navigate even for people who are experienced like there's a whole bunch of things and what you need to change is like a small thing and you don't know about edebug and all that other stuff. [Prot]: But of course debugging it many times of course it is a lifesaver for sure. [Sacha]: Yeah, and I think a lot of these things can be stepped around if you have, you know, like you, someone more experienced with Emacs to watch over your shoulder either in person or virtually and say, you know, do it this way instead, or have you heard about this package? But this is an experience that I think not a lot of people have because many times they're isolated, right? They're the only Emacs person they know around them. And maybe they'll go to meet up, but maybe they're intimidated by the idea of asking about their beginner problem with all these other people talking about arcane Emacs list things. So how do we get people to the point where they can get help? 00:29:06 Getting help: partially bridged by LLMs?
[Prot]: Yeah, I think this is partially bridged. This gap is partially bridged by LLMs. Like a lot of people will just check with a bot and get something useful out of it and basically continue from there. And that's why I said earlier they muddle through because LLMs of course will give you what you ask. So if you kind of don't know what to ask, you will get something that may be useful, maybe needs a further tweak to it. That's why sometimes it's hit or miss. [Sacha]: And I am seeing that in a lot of the discussion threads now. Of course, people are concerned about the environmental impacts and the ethical considerations around large language models, but there are also people who are saying, you know, this is what helped me write my first bit of Emacs Lisp, or this is what helped me figure out how to configure Emacs to do the thing that I wanted to do. So for that, I'm like, okay, then maybe there's something there. Challenge, of course, if it's hallucinating something, you're like, no, that function does not actually exist. You got to do it this other way. But if you can get them over some of the humps, maybe that's useful for them. [Prot]: Yes, yes, yes. I think, of course, it's not 100% good, but I think it is, on the balance, I think it is good. [Sacha]: So when people are too embarrassed or too intimidated to ask people in person, and when I go to these meetups, everyone's always super friendly. Sometimes we're live debugging someone's configuration or someone's function in real time. But sometimes that is a little difficult for people to get to for schedule or other reasons. There are other ways to understand something and ask questions about it and figure it out. 00:31:01 Things people don't even know about
[Sacha]: what to ask questions about. How do we help people in that situation where they don't even know that they're doing something inefficiently and that the solution for their problems is just one package away? How do we help? [Prot]: That's difficult because it's on a case-by-case basis. I think you cannot optimize for that because each person will have different intuitions or different pain points, let's say. And maybe you can do it by having the most exhaustive kind of documentation with the equivalent of search engine optimization, as you were saying earlier. But I think eventually people will still have questions and even the formulation of the question may be idiosyncratic. So even if the concept is there, the way it is presented, you might not have a perfect match. [Sacha]: And the idiosyncrasy of things is something that it's definitely a challenge for us when we're working with Emacs because everyone has their own way of doing things and everyone therefore has their own... How they set it up or the keyboard shortcuts that they use or the ways that they want the functions to work. Even trying to write documentation to say, if you're learning this, you might want to check out this stuff next, I have a hard time figuring out how to make that make sense to as many people as possible without overwhelming them with 20 different questions. 00:32:42 Filling in the blanks
[Prot]: That's the difficult part. Actually, I think that's the part where you have to assume that people will fill in the blanks. For example, I think yesterday you were doing this thing where, well, somebody needs to use Git, but what is even Git? So you have to even know about Git, right? And that's recursive because, well, how do you install Git? Well, you need a terminal. What is a terminal, right? Well, you need to have this thing called Linux. What is a Linux? So basically at some point you have to just say like I will give you as much as I can but I will limit it to the scope of this like Emacs basically. Because otherwise it has infinite scope. [Sacha]: And I find that hyperlinks help a lot with that then because we can say, if you need a more detailed description, you can go over there. So now I'm trying to make it easier for myself whenever I say, oh yeah, put this in your .emacs. 00:33:37 .emacs
[Sacha]: the Emacs wiki page on init files. Because there's this whole discussion that you have to have about what is your .emacs and sometimes it's actually your .emacs.d/init.el but sometimes it's actually your .config/emacs/init.el and, like, pass that off to a page to explain all that stuff. [Prot]: Actually I want to say something about this because now it reminded me. So many people nowadays will use .emacs.d/init.el or .config/emacs/init.el But Emacs defaults to reading the .emacs file from your home directory. And I had this case where a user was writing their init file in one of those specified locations, but they did something with Emacs Customize beforehand and Emacs Customize wrote to the .emacs file. So they were loading Emacs and nothing was showing up and they were like, what is wrong? My init file is there. Why is it not working? I'm loading, you know, this dark thing. Why is it white? or whatever. And eventually it was because of the .emacs file. I'm not sure how best to resolve that given that you want to also be backward compatible. [Sacha]: No, no, no. Okay. So when I tell people just, you know, here's the link to the init file page in the Emacs wiki, it also includes a describe-variable user-init-file, which will tell you which one is actually loading. And I have a to-do to suggest on emacs-devel, if they haven't already discussed it endlessly, that maybe there should be kind of like a M-x find-user-init-file that just opens that specific file. Would be nice. But yeah. Going back to the chat because people have been sharing great comments as well. Shae says, "I learned about new Emacs packages by pairing with other users and asking, how did you do that thing?" Which I think is a great thing for screencasts. People sharing videos as well because when people share a video, sometimes they see things that they wouldn't have mentioned because they totally take advantage of it. It's just something they take for granted. For example, in your live stream package maintenance sessions, I'm sure you've had this a couple of times. People are asking, what is that that you just did? Videos are great for this. [Prot]: Let me open the door for my puppy. I'll be back. [Sacha]: In the meantime, let's see if there's anything here I can address by myself. The puppies cannot wait. [Prot]: No, the puppies cannot wait. [Sacha]: Small mammals in general are like, they need us, they need us. @hajovonta6300 says, "I used Emacs since 2010 and had become a power user, but in the last year, I feel LLMs took over most of the tasks I usually solved with Emacs." I mean actually it's a bit of a tangent here but we're seeing that also with some of the long-term users of Emacs moving on to other editors because whatever they had customized on top of Emacs could be replicated by a custom application written by an LLM. The movement is going both ways. People leaving Emacs for other things, people coming into Emacs because LLMs can help them with stuff. So I just wanted to mention that because things are happening. 00:37:04 Discovery and the info manual
[Sacha]: "Emacs documentation is very extensive, but I feel discovery of the docs is a problem for new users." And I want to dig into that a bit more. How do we help with this discovery thing? [Prot]: In the info manuals, if you know two key bindings, it really helps a lot. One is g, the other is i. But you have to have completion already set up, like vertico-mode, for example. [Sacha]: I also like using s for search. [Prot]: Or s for search. Those help a lot, because then you can jump to a node or an index. Without those navigating, the manuals can feel cumbersome. That granted, we are back to the point where the user also has to do some research on their own. You cannot compensate for drive, motivation. No matter how much we write, no matter how many themes or minor modes we define, the user also has to be searching. [Sacha]: Yeah. And it's going back to the challenge of being overwhelmed. You know, sometimes it's difficult for new users to say, okay, there's so much to learn. How do I scope this so that I don't go crazy? You know, what is the most important thing that I need to learn about first? And then what is the tiniest step after that that I can take? And so forth. Otherwise, it's just like, I want to learn about everything. 00:38:34 Address your immediate need; small steps
[Prot]: Based on the discussions I have had, I think the consensus is address your immediate needs. For example, you want to write a to-do list, all you need to know at this early stage is Org Mode. And not all of Org, because Org has approximately one zillion commands. Just to-do and done. And maybe schedule a date. Just learn that, and by learning that, do that for a week, do it for a month, however long it takes for you to embed it as part of your knowledge . And then once you have done that, move on to the next thing. Like, okay, now that I am solid on my to-do's, how do I do the agenda, for example, and incrementally add to that. And the idea is by piecing together your system this way, you achieve two things. First, you build on a solid foundation of knowledge where you know what you are doing. And two, you understand how your system is pieced together. So if something breaks, you already have an intuition of what it could be. Even if you don't know Emacs Lisp, you can guess like, oh, I added this thing the other day and now my Emacs is broken. So probably the breakage is there. [Sacha]: And this decomposing it into those tiny steps so that you can piece them together and build slowly understanding each step along the way is something that new people struggle with because they don't have experience to know what the small step is. And I think that's where coaching and mentoring and you know sometimes If you're lucky enough to be able to sit with somebody who says, okay, your next step is just to do this. That would be super lucky. But most people will just have to content themselves with sometimes there's a playlist of videos that they can follow in sequence. Or maybe there's someone, you know, maybe they'll post on Reddit saying, okay, I know this. What should I learn next? I just wish it were easier for us to say... Let's imagine this from the helper point of view. How do we make it easier for people to say, all right, this is where you are. Here's some things that you can look into next. What do you do when you're coaching someone? [Prot]: Yes, I always ask them what their needs are. There are some needs which are common. For example, completion. Vertico, for example, I think basically everybody can benefit unless you have a really special use case. But other than that, it's like, well, we don't need to fix everything. Let's understand what your needs are. Let's work towards that goal. And one way to break it down also conceptually is with use-package blocks. I think use-package is an excellent, of course, it's an excellent tool in its own right, but it's an excellent way of saying, you know what? This is one thing. This is one step. And this is the next step. And so people can start thinking in terms of each use-package is a step. 00:41:45 :config and setq is nicer than :custom for C-x C-e purposes (eval-last-sexp)
[Sacha]: I sometimes feel like I'm going back and forth. use-package is nice because it allows us to add the hooks and say this stuff happens after the package is loaded, so I don't have to keep having lots of with-eval-after-load. But on the other hand, it becomes harder for people to copy and paste things because then they have to know it needs to go inside the use-package. Do I use the custom keyword or do I just use setq because it looks more copyable? [Prot]: This is why me, I don't use the custom. It's not that I have anything personal against it. It's that I found that it's unusable. If you have the equivalent of this in a custom, you cannot do C-x C-e. If you say use-package is syntactic sugar... I have read this before. To somebody who doesn't speak programming lingo, syntactic sugar doesn't mean anything. To me, it barely means anything after knowing all this stuff. So what does syntactic sugar actually mean? So what do I have to do to evaluate this, right? So I am like, okay, the more minimal you can do is just have a config and then you can do add-hook there, bind-key there or whatever. Granted, I don't do this here. I don't follow this. But I mean, if you want to have like a combination of what you were saying of the back and forth while still retaining use-package, you salvage that by doing the equivalent of this. Just this. And then everything goes under config. [Sacha]: And that's what I end up doing too. Just making it easier for me to change things and re-evaluate them with C-x C-e is definitely one of the major considerations. Okay, I've temporarily misplaced my... Some people are very lucky. They actually have an Emacs channel at work that they can ask for help or they can come across recommendations for. That's nice for learning, @Rossbaker9079 says. It's not a full replacement for these other ideas, but it brings together people solving the same problems with Emacs. Some people are lucky enough to work in a large company where other people are using Emacs. You should definitely take advantage of that. I hear there's actually a Discord server as well, and of course there's IRC, where people can also hang out and hear other people talk about Emacs, ask questions, learn from other people's questions. I don't think you hang out in IRC or any of these places. [Prot]: No, no. I haven't done it in a very long time. I have an account there on IRC. I think the last time I did, it was in the last EmacsConf I could attend, which is like maybe two or three years ago. I forgot already. [Sacha]: It's yet another thing that kind of distracts your attention. I also find Mastodon to be very helpful for this stream of little updates from people sharing their Emacs questions or their things that they've just figured out. That's another useful resource for people. I've started trying to get people... to support them in hooking up with this community, connecting with this community. The Emacs Newbie page has a link to learning Emacs, and one of those things says links to category community. Because if you're learning these things in isolation, you will get really, really stuck. And you will not progress. I think being able to connect with the Emacs community is great for inspiration and figuring things out. [Prot]: Yes, yes, I agree, I agree. 00:45:28 Culture of documentation and sharing
[Prot]: basically, like the social aspect of it. Like, well, of course, I use it as a tool, but there is a cultural component to it. [Sacha]: So tell me, what is your impression of the Emacs culture so far? [Prot]: Oh, it's, of course, we are talking about people who stick around, right? Not people who will use Emacs once and then leave. I think fundamentally it's people who care about sharing. I think the essence of it, it's really sharing. And then, of course, that is expressed sharing code, sharing ideas, and then, of course, documenting things. So the documentation culture of Emacs, I think it's really strong. Like in other free software communities, they are like, okay, we are sharing code, but then code is its own documentation kind of thing. Good code speaks for itself kind of thing. Whereas in Emacs land, we are like, okay, good code speaks for itself, but here is this wall of text just in case. [Sacha]: And, you know, this is probably something only two other people in the world will ever want to do, but here it is just in case. I love those. I'm like, yeah, that's exactly what I wanted to do, actually. Thank you. [Prot]: Yeah, yeah, I agree. [Sacha]: It's a wonderful community, and I'm very glad that you're part of it, and I'm very glad that lots of other people have joined in as well. Okay, let me go. Once again, I have misplaced my... Okay, here we go. @ShaeErisson asked, "Is there a way to ask Emacs which file it has read below the current configuration?" That's the user init file variable, Shae, so you can just describe that. 00:47:11 Link to a search
[Sacha]: "thinking of the terminology problem, maybe offering search terms for further exploration rather than or in addition to links." Which I guess like instead of just looking to a specific resource which may or may not still exist. I was going through my beginner resources and it's like this page no longer resolves but like saying okay this is this is what it's called and you can go search for your own resources, or this is the link, but also here's some other terms that you might find useful. [Prot]: Yeah, yeah. Just to add to what this person was asking, was suggesting is like, because we had something like this in Denote and eventually I implemented it. So there are two kinds of links. One is a direct pointer where it's like, go there. The other is basically the equivalent of a button that triggers a search. For example, let's imagine in terms of files and directories, like a direct link goes to a file. A query link, you click on it, it opens a directory listing of all files that match the query. And that is basically evergreen. It will always show you whatever is matching. And maybe we could have something like that for info buffers, where instead of a link to a node, you do that and it produces a listing of all nodes that match the query. [Sacha]: Hmm, that's quite interesting. Or like when we, you know, if we're writing about something, we can say, you know, here's the apropos command to go find all the commands, things that are related to this concept. Even just getting people to learn about how to use apropos, I think, would be a great step in helping them. Even before that, just getting them to a completion setup where they can ideally use something like orderless to just find things. Yeah. I think it would definitely help with the discoverability thing. [Prot]: Yes. I think like Vertico and Orderless are like... if you have to install two packages, it's those two. [Sacha]: Yeah. It is great. Okay. Where are we now? I keep... We've talked about the sandwich that has to be made. We've talked about getting people into it, helping them discover concepts, helping them connect with the community. And then there's a thing about how do we support people as they do their lifelong learning. 00:49:48 Getting through the gap between beginner tutorials and the next step
[Sacha]: maybe they'll get through the tutorial fine, but then when they start to try to do something more sophisticated, like, oh yeah, I need to do something similar to my IDE. I want to have all these different bits and bobs working the way that they do in my other editor. That's where things break down because the tutorial gets them through the, you know, here are the basics, but then there's this huge gulf before that, okay, this is how I can be more productive with it. How do we fix that? [Prot]: Yes, that's very difficult because part of that requires Emacs Lisp knowledge. Like, for example, an IDE, of course, I haven't used one myself, but from what I understand, there is a sidebar with the tree view of your files. At the bottom, there is a shell. Maybe there is some debugger there, some other sidebar on the side. So to replicate that, you really need to massage the display-buffer-alist which I think requires a lot of knowledge, like you need to understand the display buffer, you need to know about window... what's it called? Even I forget. Attributes and all that. [Sacha]: I don't even do it myself. If I feel like I need to do anything related to display-buffer-alist, I'm just like, okay, I'm going to look for an example and I'm going to copy it very carefully. 00:51:08 Predictability
[Prot]: Okay, so this is for you. It's like too much work, but I must say. This looks like arcane knowledge but this sort of thing actually is a quality of life improvement to your Emacs because one thing that I think is bad about the default Emacs experience is uncertainty about where things will show up. Like, you never know. Like, you cannot predict it. Because Emacs tries to be sensible about it or whatever, but you cannot predict it. Whereas things that are ancillary should have kind of a more predictable behavior. 00:51:51 Brief mention of Popper
[Prot]: by Karthik Chikmagalur called Popper. I didn't mention it, but yeah, it's basically another way to do the display-buffer-alist. [Sacha]: Mm-hmm. So there's an interesting thing here where you have the beginners. Okay, they're just getting through the tutorial. If they can get to the point where they can edit the file, click on, even just use the menu bar to say file save, file open and all that stuff, that's great. Then the step beyond that is, okay, how do they start to use packages? And quite... 00:52:25 Earlier is better than later for Emacs Lisp. Take it as is.
[Sacha]: to be able to use packages like Popper or all these, they gotta be unafraid to use Emacs Lisp. Because all the packages, you know, tell them, okay, just put this use package in your config, but you gotta be comfortable. [Prot]: And that's why I think you have to basically circumvent Customize. Like the earlier you are exposed to Emacs Lisp, I think the better it is for you long term. Because there is no way around it. You will have to deal with it. and even if you don't quite know how things work, like even, for example, this thing here, where it's like, there is a line between them, even if you don't understand code, you can start to think in terms of blocks even if you don't understand this code... Maybe with a few comments here and there, that can become a bit more obvious as well. But of course, like you go to a package and the first thing it will tell you is, okay, add this to your config and it's a use-package declaration, for example. And you will be like, what is a config? The better solution is for you to know that quickly, learn it quickly. [Sacha]: There's this whole intimidation factor, especially for people who are coming from non-programming backgrounds, and suddenly they're like, there are a lot of parentheses in this. Do I have to be a programmer in order to use this? You just go right into it, but I'm sure you've talked to people who maybe weren't sure about it. How do you get them over that hump? [Prot]: Basically the idea is treat it as something that is inscrutable right now. Just take it as is. Take it at face value basically. You don't need to understand it. You don't need to be able to debug it. Take it as is and just make sure moving your cursor that this kind of balance is preserved by checking that there is a parenthesis at the beginning and there is a parenthesis at the end. So, show parent mode helps in that regard, which is enabled by default. Of course, you cannot really get around it. Like, you cannot have a training wheels mode for Elisp, unfortunately. You can do something like rainbow-delimiters, you know, the package. You can help, but I'm not sure that helps by a lot. [Sacha]: Yeah, yeah. And it's like, OK, so you just got to do it. Don't be too scared. But it's OK to just copy and paste and trust that as you do this, you will learn enough that when you go back, you'll be able to understand more and more of it. 00:55:17 Before and after comparisons
[Prot]: Yes. What helps, for example, in this block here, of course, I don't have to describe the code. But if you do this iterative approach that we mentioned earlier of step by step, like you can try your Emacs before this and after this. And based of course on some comment or whatever, you can see what the difference is. So even if you don't understand the code, you understand the effects of the code. [Sacha]: Yeah, yeah. Before and after comparisons. I'm guilty of not taking advantage of this enough myself. I'm just like, oh yeah, I'm just going to evaluate it in my current Emacs and sometimes the results are obvious and sometimes the results kind of break my Emacs and I'm like, okay, I got to restart Emacs instead. I should have just started a new Emacs and tried it there. 00:56:04 user-init-directory
[Sacha]: but actually --user-init-directory has been around since Emacs 29. So it's pretty much widely available now. People can actually try, for example, a starter kit without committing to it. Do you see newbies actually use this? Because I tell people, okay, you can do this, but it requires using the command line and using command line arguments. Is that a thing they can do? [Prot]: I have introduced it to some people and they have used it, yes. But I don't know if people use it as part of their workflow or maybe they have just a cheat sheet specifically for this where it's like, oh, I want to try this and I want to try that. But eventually they don't use it day by day, I think. They just settle. [Sacha]: if you want to try something big, then you know you can say, try that starter kit, but don't necessarily go to the work of making it my .emacs.d and so forth. Yes, that's a good one. They just say put this in your init file so it's a lot easier to back it out and change your mind. I had a thought, but it has disappeared, so I will just read something else from the chat. [Prot]: That's fine. 00:57:20 Emacs core
[Sacha]: @romsno says, "Do you fear that Emacs C core will go unmaintained? Deep knowledge is rare, held by few, like Eli. While finding Elisp maintainers is easier, like with elfeed, the core is hard to replace." So I guess if you're thinking about the long-term: newbie, to package user, to package developer, to who knows, Emacs core contributor, And then off to the C, like somebody who knows the C core, that's a very long and somewhat leaky pathway. [Prot]: It is for sure, for sure. But of course, here we are talking about people who have expertise in those specific domains. And yeah, that's something that it's an experienced Emacs user already. Like we are talking about somebody who not only is actually an experienced Emacs user, but also knows the relevant technical knowledge. Right. I am an experienced user, for example, but I don't know C, so I'm useless in this regard. [Sacha]: I guess if we zoom out a little bit, we can think about how do we help people connect with the long-term motivation that drives, that you mentioned earlier, to keep using Emacs, to learn more about it, to enjoy using it and fiddling with it and get deeper into it. For some people, Emacs clicks right away because they already tinker with other things and it becomes another thing to tinker with. For some people, it's like, I don't know, I've heard I should use this or I've heard people say good things about Org Mode or about Magit. I just want to see what it's like. 00:59:02 Getting past the initial awkward phase
[Sacha]: [Prot]: Yeah, yeah, yeah. It's that initial awkward phase. Like if they can get past that, and by awkward phase, here I mean to actually understand Emacs and the key bindings and how to move between windows and there is a mini buffer, that sort of thing. Once they get past that, I think that people stick around. Like if they have, for example, a use for it such as, okay, I use it for org, they do stick around. 00:59:34 Even reporting an issue is a great contribution
[Prot]: like even non-programmers. And this is something I encourage in my packages, for example, where it's like, write me an issue. You don't need to know any code. You don't have to tell me about how to do it. Just tell me what your idea is. And in all my manuals that I write, I have an acknowledgement section where I have, you know, ideas or suggestions or whatever. And I write the name of everybody who has ever created an issue because it's like you help even by telling me what your use case is. And that already helps. And it gets the people involved as well. [Sacha]: They spend time trying it out and describing what the difference was between what happened and what they wanted to happen. And sometimes even just identifying the issue is a big part of it already because you can't test everything. So we can definitely help people feel more included in the community because they don't have to be core developers or package authors to be part of the community. Even using it and writing about it is a big help. 01:00:44 Next steps: adding to the wiki
[Sacha]: I have to make a grilled cheese sandwich, shall we wrap up with some concrete things that you or me or somebody listening can do to help improve the newcomer experience for Emacs? [Prot]: You were doing it already. You were doing the wiki. I think that's good. A link, a direct link to the newbie section I think is great. Maybe you can even have a permanent link in your Emacs News, like the topmost line. It would be like, well, new... [Sacha]: Don't get overwhelmed by all these people talking about SDL graphics loops and Emacs and whatever. Very far down the path of the learning journey. So making one of these starting points where people can then kind of find the trail that then leads them to different places. I'm looking forward to reviewing the Emacs news things for beginner resources that I've already previously identified and then fitting them into the Emacs Wiki in various places where people might come across them. And then of course, it would be nice if we could test these with actual people. So in your coaching sessions, we can find out where the other gaps are. There's a lovely conversation in the chat about other things that I don't have the fast speaking rate to cram into the next three minutes. Thank you so much for this conversation. It was great. I always like picking your brain about things. It's a big project but Emacs is fun to play with and I hope lots of other people come to have fun with it too. 01:02:37 Core longevity
[Prot]: Yes, and maybe I can make a final comment about the C core and the fact that there are a few people such as Eli Zaretskii who have expertise in that. I am an optimist. I think things will be ironed out. I think they will work out on their own. There are people who have the expertise. Maybe it's a cultural issue or We could say like a bureaucracy issue, like they don't want to deal with mailing lists or whatever. Maybe they don't like the current style. I don't know. But I'm sure that when push comes to shove, somebody will step up. [Sacha]: I think it's actually very encouraging that because Emacs has such a long history, we've actually seen this kind of generational transfer of knowledge already in the sense that the people who are maintaining Emacs now, aside of course from Dr. Stallman himself, they're not the originals who started this project. They came into it afterwards, decided they liked it, dug deep enough into it to learn all these different things and have continued from there. And we've also seen lots of, you know, lots of trends come and go. People leave Emacs for Atom. People come back when Atom gets discontinued. People leave Emacs for VS Code. Who knows what will happen then? But when they come back, they come back bringing even more ideas. Thank you for watching! Okay, so in about one minute, the kid is going to start barreling down the hallway and asking for a grilled cheese sandwich. I'm going to wrap it up nicely here so I can remember to copy the chat this time. [Prot]: Very well, very well. [Sacha]: Yeah, yeah. The notes are going to be in, like, you know, if you go to yayemacs.com, they're probably going to be in, like, yayemacs24. And you're going to send me this markdown file or whatever that you showed me, so I can post that as well. Thank you so much, everyone. Thank you, Prot, and thank you to the people who joined in the chat. We'll see where it goes. Okay, bye. [Prot]: Take care. Take care. Bye, Sacha. Bye, folks. Take care.