0:00 Opening
Sacha: I'm going to start recording. I'm going to do the thing. I'll let you know. Okay. Let's do this. Yeah. Prot: Yeah. Sacha: Yeah. Okay. Hang on a second. Starting, going live. Okay. So, hello, everyone. This is Yay Emacs 29. And today I am here with Prot and Philip Kaludercic. We're having this conversation about Emacs newcomer experience, which started off with an Emacs carnival last month about newbies and starter kits, which Cena started and you fleshed out with more questions. And now this is snowballing to, okay, let's figure out what we can do to make Emacs easier for newbies who are coming in, maybe they're non-developers who have heard good things about Org Mode, or maybe they're developers who want to try out what this Emacs thing is and what's all the fuss about having an editor that's been around for so long. Or maybe they're actually still VS Code or Vim fans, but they really just want to use Magit, so they're coming in just for that. A lot of different paths to coming into Emacs. We do have this live stream, so if people have questions, I will at some point figure out where the chat is on my screen so I can read them out to you. But my plan here is I'll just be in the background taking notes most of the time and interjecting with occasional questions. And maybe Philip and Prot, you can go brain dump all the wonderful things you've been thinking about the Emacs newcomer experience. Philip: At this point, regret not having written down any notes from the last video or from your last recording of YouTube, because I noticed I had a few things I wanted to add or intersperse. But I guess we can take a look at two things. So first one is the state of introducing people to Emacs now. And the question there is, who are we introducing Emacs to? Just like you said, you sketched out a few different profiles of people who presumably have entirely different Interests, motivations, like if someone wants to just use Magit like Emacs is there. It's the tool, it's the GUI that implements Magit, then these people have an entirely different motivation than someone who actually says, well, I'm coming at it from, I heard it's an interesting tool for free software development. Build your own or like understand free software in a different sense where you can actually do find function and open the definition of the function you just use. And I think malleable is the current catch word that people like to use in that context. So there's some issue in that sense. 2:59 newcomers-presets user option theme; would be nice to explain what the changes are
Philip: And then the specific comment from the last discussion which caught my attention was We were talking about Emacs 31, there's this preset theme, the newcomers-presets theme, which is implemented as a user option theme, or that's how I like to refer to it. And I probably should just briefly stop and say that everything I'm saying is from my own perspective. I don't feel comfortable saying that this is the Emacs level perspective or that any other of the Emacs developers necessarily have to agree with me. I just think that I might have a few things. Prot: Sorry, I lost your audio. Just to say I lost your audio, Philip. Excuse me. Sorry, I lost your audio for a second. You could hear it fine. I will hear it in the recording. Sacha: Okay, so basically, you can repeat it, I guess. Go ahead. Philip: What did I say? So you were saying that... I'm not representing emacs-devel. These are my views which are informed by the discussions that we had in emacs-devel that I hope will be represented. I think I'm the maintainer of the preset theme, but of course other people are also contributing to it and adding other options. Specific points I had like the target audience of the preset theme was not people who would be particularly interested. What the options are. I think that was a discussion point last time. I admit it's a technical deficiency currently. There's no pretty way. I think it would be nice if we extended describe theme to actually list the options that are modified with hyperlinks so that you could look into these options. That's currently not there. We didn't add it in time for the feature cut for Emacs 31, but I think for Emacs 32 that's going to be an interesting Feature to have at some point. 5:00 finding a balance between "it's fine the way it is" and "just use Doom Emacs"
Philip: And actually the idea had been floating around I think like every time there was like there's a periodic, periodical discussions like how should we make Emacs more user-friendly on Emacs level and people say we have to like say the extremist position is what do you mean not user-friendly. It's perfect the way it is. It's God-given configuration. And the other people who say, well, why don't we just install Doom Emacs and make that the default then? Somewhere in between, I think there is a reasonable position to be had. But in these discussions, one of the reasons this came... I participated maybe in like... Four or five of them and then this point came up. Why don't we have a theme like a collection of user options which you can toggle in one switch which enable all the options from which we would not find which existing users would not find interesting which are always the bulk of the users most people are already existing users they don't come in and one of the things are lots of existing users I'm thinking of like A 60-year-old professor who has been using Emacs for 30 years or a software engineer who's using it and maybe consciously or unconsciously appreciates the fact that it doesn't change every few years. You don't have a graphic designer. This is, of course, me against graphic designers and UI designers who have a need to reinvent the UI interface every few years and then things change. And how do I save now? What's the... What's the button to do this? And the UI changes. 6:37 people value stability, but also conventions have shifted.
Philip: The people who value the stability. But of course, the common conventions have grown apart. What Emacs does and what people are used to from other programs. 6:50 ways Emacs does things differently: ex: terminal vs eshell, output is editable; new users want to edit the previous prompt; sometimes goes against people's intuitions
Philip: Now, at this point, we also have to distinguish that there are things which Emacs doesn't do the way other programs do, which are... Which I would argue are actually sensible. For example, I think one issue I remember was when I first started using Emacs, I had a terminal emulator. I wanted to have a terminal emulator within Emacs. Nowadays I use Emacs Shell, which to me seems like a more truer Emacs experience. It's an opinion, a strong opinion maybe. And it's also influenced by a history of using Plan 9 and that kind of terminal where actually the output is just as editable. You can just search it. You can edit it. You can cut it. You can interact with the output any way you would use a normal text, which is not something you can do with a terminal for purely historical reasons. At my university, the university where I studied computer science, I frequently helped people in the introductory Linux course. One thing you notice there, these are real newcomers. These are people who have never used Linux or a terminal or anything like that before. The first thing they do when they want to, like, they use the arrow keys expecting or click on, they use the mouse and click on the previous prompt. And they want to modify the previous prompt. Of course, that doesn't work because that's not how terminal emulators work. All the previous output, that's fixed. You don't touch that anymore. Everyone, I guess even people who we describe as newcomers, Talking about Emacs. Obviously, no. Of course you don't touch the previous prompt in the terminal. These are some expectations you have if you use Eclipse, if you use VS Code, if you use... I'm not sure how the NeoVim terminal emulator works. I know they have a built-in one. I think Vim also, but I'm guessing right now. So there are some accumulated intuitions which Emacs actually intentionally doesn't want to give. doesn't want to give in all purposes because I'd argue that one of the strengths of Emacs is really having this uniform text interface where I can use I search, I can use occur, I can use the highlighting commands, I can just select a region and write it out to a buffer. And stuff like that. That shell buffer is no different than anything else in that respect. Please interrupt me by the way. This is not supposed to be a monologue. Prot: No, no, no. Go ahead. Sacha: So it sounds like there's an interesting challenge here. Philip: Breaking some of these intuitions is legitimate. Sacha: Yeah. 9:21 How do people develop Emacs intuition? Immersion
Sacha: How do we help people develop the Emacs intuitions? Philip: To some degree, it really feels like it has to be something that you immerse yourself in. The issue, I guess, is, well, I know, I mean, I knew people who actually used Emacs. I mean, you can help them in a face-to-face setting or like Prot does in his teaching settings. Then you communicate certain things, which I don't want to say they're ineffable. It's not like you couldn't write them down in a manual, but it's also... Like the mentality that people have. 9:55 example: dabbrev, there's no undo? Ah, it's just the regular undo.
Philip: A different example I have, like, I remember I was using daabrev for the first time or something. For a while I was irritated. There was no undo. Like, how do I go back to the previous text expansion? Until at some point I realized, oh wait, it's just regular undo. That's just the way you undo it. But somehow writing this down in a manual is... It's not an easy thing to always think of these things. For me it seems obvious now, but at that point I specifically remember it was unintuitive. I had this accumulated expectation from other programmers if I have a text expansion in this case that I'm actually cycling through some special sort of menu, not thinking of it as just regular text buffer operations. Just text editing in some fancy way. But that's one We should keep in mind. This was all related to the preset theme in some way, right? You're writing this down. Sacha: Yes, I'm writing this down. That's why we have notes. 11:00 newcomers presets: smooth over the intuition-disrupting things that are not actually necessary/beneficial; ex: enable whichkey
Sacha: So what I'm thinking is you wanted the idea behind the newcomers presets is to kind of smooth over some of those intuition disrupting things where people are coming in with maybe expectations of how stuff should work in a modern editor. Philip: Specifically the intuition. Go ahead. Specifically the intuition-disrupting things which are not necessary, in some sense. Like, we wouldn't want to be an intuition disrupt... like you could probably... Like Cua mode or something that would be something where people if they would start using... If you would enable Cua-mode by default, that would inhibit further development, because then it might be confusing with using C-c, like if you... because suddenly Delay becomes a user input, which is usually not the case with Emacs. I know which-key is an exception in that case, because which-key pausing actually is an action and displays a pop-up buffer. And we do enable which-key due to popular requests and the preset theme. I personally was a bit hesitant about that one, but it seems to be something. where you have to really weigh it on a case-to-case basis. But, Sacha, do you have the... What version of Emacs do you have running there? I can't make it out. Sacha: Yeah, this is Emacs 31, so I do have... So you can open the preset theme, right? Yeah, yeah. Hang on a second. Let me bring up a... I have now a terminal, so I can... Let me bring up a completely fresh Emacs. Philip: No, I just wanted to open the file. Because in the file there is a prelude. There's a commentary section that actually explains the curve. It's not a library. Prot: That's exactly the joke with the... Yeah, that's part of the problem with those themes. That's the problem. Wait, really? It would be easier if they were all there. It's a kind of an implementation detail that from a user it doesn't really make a difference. Philip: You have the same problem with all these things, if I remember correctly. Yeah, yeah, exactly. Yeah, and you see up there the commentary section? Sacha: Yeah. Philip: If you scroll up a bit, it's above line 37. The theme configures which we can reasonably expect the average user to want to enable, but would otherwise be unlikely to discover on their own. That's sort of the overall guide of what options we want to add. That's why it's also an option on the splash screen. You just tick it and then the user options enablement theme should be activated by default. Sacha: That's sort of the idea. So it is available on the splash screen. So if I say display splash. Oh my goodness, how do I get to the splash screen? Prot: It's C-h C-a or not? I forgot. There are two things. Sacha: There's a splash screen and there's the... Hang on a second. I'm just going to start a new Emacs. Prot: Yeah, I haven't done that in, like, I don't know. That's the about Emacs screen. But you have a display splash screen. C-h C-a on mine. About Emacs. Emacs about Emacs. Sacha: Then I have a better idea. I'm going to start this new Emacs person. Okay, here we go. New Emacs. Fresh person. 
Sacha: So we click on this, right? And it turns on a bunch of things including the tab bar. 14:32 newcomers-presets choice is not saved at the moment
Sacha: I wasn't entirely sure how people would save that so that it happens again next time. Is the idea that they just keep checking that box? Philip: That's not done currently. That's something we haven't simply decided on. The current presentation is you enable it in that mode and then you'd have to, which is of course saying it out loud makes it sound stupid, but you'd have to persistently save the themes. So then I think it's optional to save themes and then... 
Sacha: It is possible for people to get to it if we leave them a breadcrumb. But it's not going to occur to them because it would never occur to them to say customize Emacs, custom themes, and then I can pick newcomers themes from here. Philip: It's a point that I at least intended to mention at some point. Emacs level whether we want to make this because currently it just loads the theme but it doesn't persist the choice but it could just as well persist the choice. There's a discussion to be had which of these two behaviors is more intuitive because of course if you persist the option then you have the disadvantage that someone might enable it but doesn't actually want it but now somehow their Emacs is broken from their perspective. I don't want tabs or whatever they say or I don't want which key and they don't know how to disable it so this is I wouldn't say it's an obvious decision in either direction. Prot: Like if there is an enable button or save, there should be a disable and unsave, like remove. Yeah, that's the checkbox idea in that case. Philip: That would be the tricky part. And especially finding the place on the splash screen so that this actually works for everyone. Because if you open it in a TUI mode, I think then initially, if I remember correctly, we had this button or this new to Emacs line was underneath the copyrights. No, no, that was a different thing. 
Philip: If you click on newcomers preset, for example, then you are redirected to the manual entry. And I think we had some, yeah, there's this, the top line. If you got here by clicking the link on the splash screen, that was on the bottom. That was on the bottom of the manual entry. But if you open it up in an 80x24 terminal, you wouldn't see this line. Sacha: You can't see it and you don't know how to... These are the complications that you have to keep in mind in that case. Philip: You might not have the intuition to space the scroll, which I think that's the case in less. But yes, again, you have this accumulated intuition from using Unix tools. Which is one of the points I wanted to bring up. 17:08 newcomers without much computing experience might even find it easier (no C-c expectations, C-v etc)
Philip: Who is this mythical newcomer? What's their actual background? Because I claim, and this might be controversial, that if someone's actually new to using computers at all, which is something I have seen, like people who have never programmed, people who have never used Unix, people who have never used more than a web browser, to exaggerate, they appear to do fine with Emacs because they have no expectation of using C-c, C-v, C-c, and so on. They know that they have to use the buttons up there. So in that sense, they're fine. There's an optimization loop when you're used to these shortcuts and a few of these conventions how to move around, that Emacs defaults appear to be inconvenient. So that's also a distinction you have to make in that setting. Prot: Exactly, exactly. Plus you cannot optimize for everybody. Eventually you just have to make some assumptions. Philip: Exactly. But what these assumptions are is the controversial... Prot: I think the way you approached it makes sense. This is the reasonable way, I think, to do it. You have to assume that they have this background knowledge. And if they don't, it's what you said. They don't have to relearn something because they didn't know it to begin with. So they start from a good basis. 18:30 Focus group?
Sacha: Is there interest in having some kind of focus group or something like that so that if we come across newbies, we can say, hey, you know, the developers would like to be able to float some questions once in a while to see what actual newbies would think of this? Philip: I have actually tried this once. I was in a hacker... what's it called? There's this computer club in Germany and they have local events on a regular basis and I was going to one anyway because a few friends of mine were going there and then I did an introduction to Emacs course there and printed out a survey basically, a questionnaire for Emacs neophytes. I think if you search for that string on the Emacs development list, you're going to find that. And I gave a few people these texts. I printed it out. It was actually pieces of paper, so it wouldn't be personally identified. There wouldn't be any information there. And one of the things I thought was interesting in the results was that the main thing people were saying was it's overwhelming. Like the amount of things... Just the default Emacs. No configuration, no options, no auto-completion, no fido, whatever. It was just so many new things, so many differences that they lost an overview, basically. This was a group of people who, I think there were questions, and they were like, how long have you been using computers? Because, of course, it was so generic. What previous UIs have you had experience with? Most people use Eclipse or Vi, NeoVim and even reasonably complex Vim configurations. Of course, this is a bias due to the setting in which I was asking these questions. I'm actually planning to repeat this experiment because I'm going to another one of these congresses or these meetups in a month or so. I wanted to offer this again to people, specifically seeing if these newcomer presets are valuable or if they help people or not. But of course, doing this in a properly scientific setting would be much more difficult. Yeah, of course. We need money. Difficult steps of doing this. Sacha: Maybe even like a mailing list. We can say, hey, you know, you're new to Emacs, but you kind of want to make it better. Email this person. And every so often when developers have a question, they can say like, does this make sense to you? Here's a screenshot. Or would you prefer this versus this? Philip: As in, we would send an email to all the people, but then I think, I mean, the big question, difficulty in that sense is then data protection, I think. That's what I was trying to avoid with having this just printed out and no personal identification, because then we have to store email addresses. Sacha: Okay, all right. That's fine. Philip: That's fair. So, sounds like an excuse. Partially it is, but something like, I mean... I'm not saying that my approach, what I was doing was unbiased. There are people who would be more willing to answer these things and people who are less willing. I know the bias in this case because I actually saw the people and I had a feeling for what kind of people they were. So I think I'm in a better position to factor it out. But if it's actually properly, if you just have people who you send emails to 22:15 Emacs survey before
Philip: I'm not sure if it remains represented because there have been these Emacs surveys in the past. I remember at least two generations. And they're of course the ones which are circulated on Reddit, on Hacker News, on IRC, which I still think is a bubble of maybe 200 people. Like mainly 200 people and some people who are Surrounding these groups. So I'm always sort of dubious because these are the people. 22:48 people's backgrounds influence their responses
Philip: I mean, these are people who are much more likely to have heard of, what's it called, Evil Mode or something like that, or had some experience with other editors. And these things all influence their responses. always taints the results. Every time these discussions are brought up on Emacs devel, people have some level of doubts as to how reliable the results are. Prot: Correct, correct. It's hard to get reliable results, though some data is still better than nothing. But granted, you don't want to base decisions on those results, of course not. Philip: Yeah, that shouldn't be the last decision-making factor. You should just have a function where the input is whatever the data is, and then the output is mechanically determined by that. Yes? 23:46 Hypothetical: Reset themes, to reset things back to the defaults of a specific Emacs version
Philip: Now, related to the preset theme, there's also been a discussion (I don't think this has been mentioned much online) of so-called reset themes. I'm not sure if you've heard of these. So the idea would be, additionally to having preset themes of options, which we have changed, which we would recommend because the newcomer preset theme makes no real assumption that the options will be stable, so we might change them from version to version, this gives us some flexibility to say we have a new option. Like, for example, if the preset theme had existed since Emacs 29, and now in Emacs... 24:22 package-autosuggest-mode suggests based on file extension
Philip: That was actually the reason this entire discussion started when Emacs 31, that's the current release... to be released, there's this package-autosuggest-mode so that's a little prompt, when it's enabled, a little prompt in the mode line. You can click on it, Emacs installs the package which it believes to be the right one for the current file. Prot: The major mode, right? Philip: No, it's a minor mode. It's a global minor mode. Prot: No, no, I mean, but it installs based on the major mode, right? Philip: Ah, yes, yes, yes. It installs a major mode package, which matches the current file format being used based on auto-mode-alist or the magic, what's it called, magic file alist and all these things, and it can... We didn't want to enable this by default, but we wanted to enable it for newcomers. That was actually the first option in the newcomers preset. If the preset had been older, we would have still wanted to add this to the preset theme. It's not supposed to be set in stone. Now the idea with the reset theme is, and this is still hypothetical since we haven't implemented it, is to have reset themes for specific Emacs versions. So we, in Emacs 32, we might have an Emacs 31 reset theme for all the options that we have changed in Emacs 31, in Emacs 32, so that we could reset them to the previous option. So that in this sense too, if the discussion, if the question is really just, we don't want to annoy people who have... When upgrading, of course, it's still a minor inconvenience because they have to write load-theme emacs31-reset in their configuration, but it would be easier for them to actually undo any changes. And in future versions of Emacs, hopefully also persist these changes so that you can really sort of like pinning your version of Emacs, a soft pinning of options. So this is something for the future. Consider as well, which would be reusing the theme approach, which is another reason why I hope that the notion of user option themes will become more, because it's been there from the beginning. The Customize system has always supported user options to be added, but people have always only customized, not only... I'm not sure no one has ever done it, but it has not been a popular approach to use the user options, even though the technical facilities have been there all the time. That's also going to be interesting if the reset theme would be forwards compatible. But that's another discussion that makes it even more complicated. So that you could add them hypothetically to ELPA as a core package. Prot: Nice. Yeah. Of course, the reset themes, if you implement them, that's great because it opens up the possibility to be a little bit more ambitious with the defaults and break. Philip: Yeah. Because that's exactly... Every core... Every default discussion boils down to: if we break this, people won't understand what changed. If we change this, people won't understand what broke. But on the other side, people like all new... Can we reasonably assume that all new people would actually want this theme? Then we want to give us some sort of more flexibility in this sense without actually the support, because I think that the value proposition of having a stable interface where you can expect the appearance of the theme to be somewhat stable over time, how Emacs behaves, that's actually a positive thing. 27:52 Emacs 32: bundled versions of Emacs (Big Emacs - distributions that include more packages)
Philip: And finally, in Emacs 32, this is also a finally. For now, one thing I just thought of, which I was reminded of, there's a big plan for Emacs 31. This is one of, I've never pronounced his name, Sean Whitton, I think it should be pronounced. He said that one of his plans as a maintainer will be to work on the bundled version of Emacs, which some people, including myself, have been calling Fat Emacs. So adding, selecting certain packages from ELPA, from GNU ELPA, and bundle a secondary distribution of Emacs which would include additional packages, Which are currently, so for example, one example would be org-tex. And then you could, when you install Emacs, you could install, I don't know, big or fat or whatever... Big Emacs with all these packages pre-installed, which would be pinned to the right version which we would have hopefully ensured that they're actually compatible with one another. And then you have the normal Emacs, which would be the thinner one. And an interesting corollary of all of this would also be that if the way from ELPA into the core would be made easier, that the way out of the core into ELPA would also be made easier. Because that would mean it's more easier to deprecate packages over time since you can install it. This protective layer, let's say, protective layer, protected merely by inconvenience and the annoyance of moving these packages in and out, would fade away over time. Some cruft within Emacs itself, within core Emacs, could be moved to ELPA. So we could actually thin down Emacs. That's one possibility. Oh, that's big. Yeah. One strand of commentary in that direction. That's something that I'm planning to help in the Emacs 32 development cycle. Because these options then could also be in... Any options related to this could also be added to the newcomers preset theme. 29:54 Selection versus multiple completion
Philip: So one could of course... Vertico or these interactive selection packages... I think I've commented that before there is a certain controversy there. I think that there's a certain controversy that selection is not always the same as text expansion, which is sometimes like... There are, I think, the certain... skeleton, or there's this insert... what's it called, auto-insert command... It's not auto-insert, something like that, that prompts the user for multiple things, but it's not written using [completing-read-multiple], but it's written in a way that there's a manual loop, which waits for an empty input to occur. But if you're using vertico or fido, by default, if you just press RET, you don't actually have an empty input. You just select the default option. There's settings like these which where these sort of these two kinds of completion diverge from one another which which is also something I've been talking about for a few years but never came around to implementing that there should be an API distinction between actually selecting user options from a list and the completion interface which we have for files or commands currently. These are semantically two different things, which would be interesting to see if it would be worth distinguishing the two in a technical sense, because that would mean that in certain settings, we could enable Fido. I totally admit that Fido and Vertico have their advantages when it comes to discoverability over standard text completion. The compromise now was that in Emacs 31 there's this option, I think it's eager completion updating or something. It's a combination, it's a permutation of these words in some sense. So that's if the completions buffer pops up. No, you don't have to... It doesn't matter. You don't have to visualize it. Yeah, where they update as you type. Updates as you type, yeah. But that doesn't occur down there, but it only occurs in the completions buffer. That's sort of a compromise. That's Fido, right? Prot: But the generic completions has had a lot of improvements over the last few years. And in Emacs 31, it's in a very good state, all things considered. Philip: Which was also partially driven by your MCT package? Prot: MCT, yeah. Which was an experiment, of course. But yeah, it's basically that idea. Because I have used this in earnest, like the default like this, I have used it for a long time in earnest, like just defaults. It's very good. It's for sure very good. Whereas Fido and Vertico are better if you are just getting started and you don't know that there is a completion on the mini buffer and somehow there is a distinction between the two. Like, for somebody who is getting started especially, I think this interface is not good. But if you know what you are doing, I think this interface actually works perfectly. And it has a lot of options. So, Sacha, what you are showing there is the absolute default, but it has so many options that you can make it look actually quite different from this and very similar to Vertico, for example, in terms of the user experience. I just realized that... Sacha: Oh, I just realized that if you do the TAB TAB, if you do the TAB TAB, it now goes to that one, which is great, but you can't filter it from there. You can't type into it and have stuff happen. Philip: Yeah, it's not down there. If you're down there in the mini-buffer, you type. There you have just a regular text buffer, so you can search or you can select stuff out of there. Prot: And that's also an option, by the way. So what happens on the second tab, for example, so you can configure that. Sacha: Right, so that was the second tab behavior from newcomer-presets. Philip: That's the option I proposed and then objected to. Sacha: Yes, work in progress. So basically, you have these newcomers. We're trying to figure out how to get them through their learning journey. The newcomer presets can smooth over some of the edges. It can get over that "Yes, there are a lot of options, but at least M-x with tab completion will show you the things so that you don't have to memorize the names as much." You can recognize them from the list. You can narrow it down. Philip: The behavior is supposed to actually be similar to Bash. Yeah. 34:39 Manuals
Sacha: It's probably still... we're going to need them to read the tutorial and we're going to need them to use a lot of patience as they get used to Emacs. I am not quite sure yet if we can get them all the way to, all right, here's how you open your config file and define your own keyboard shortcuts, for example. Bit of a journey. 35:08 More examples?
Prot: I think that one way to do that is to have more examples in the manual. Like, here is how you do this, here is how you do that. Philip: Or there's this other manual, the Emacs FAQ. Prot: I don't mind where it would be, like FAQ is totally fine. I don't mind exactly where it would be, but somewhere in the documentation, like common patterns of Emacs configuration kind of thing. Maybe it already exists, so if it exists, then of course even better. Philip: Emacs FAQ has some things on finding relating packages... Where is the FAQ? Sacha: It's a separate manual. We do not have it from here, not from the splash screen, but it is available from the Help menu. Philip: I think it's not been that thoroughly maintained. 36:21 find-user-init-file?
Sacha: I'm going to take advantage of the fact that you've actually been reading emacs-devel. Has there already been a long discussion about whether a M-x visit-user-init-file makes sense? An interactive command that you can use to open... I was trying to find it, but even with Yhetil's search, I was like, okay, there are four threads. One of them was a long time ago, and the other one was from even longer than that, so I didn't know whether it was some other discussion. Philip: I don't recall any such discussion recently, but I also don't think that anybody Objection to it. So it's really just a matter of someone writing it down and adding the documentation. Sacha: I would like to do that. Philip: It would be quite likely 24 hours. Sacha: Okay. Philip: On the master branch and not Emacs 31 branch, which would be slightly. It's fine. Yeah, but even having a button. Sacha: If it makes it in someday, it doesn't have to be in the splash screen. It just has to start off being available through... And then we don't have to keep telling people, oh yeah, do a describe-variable on the init file just in case your init file is actually .emacs instead of the .emacs.d/init.el that other people are telling you to use instead. It's a bit of a mess, right? Philip: I think some people have been recommending doing M-: and then calling the [find-file] function with the user init... What's the name of the variable again? Sacha: user-init-file. Prot: User Emacs file. Sacha: Here we go. user-init-file. Here we go. That's the thing. Yeah, exactly. Philip: And if you do M-: (find-file user-init-file), then it would basically do the same thing. That's why I'm saying it's such a minor function that I don't expect any objections. Sacha: Okay, okay. So I'm going to suggest that to Emacs Devel at some point. Philip: I've had the same idea many times myself, but the transience of memory has thrown its way before I actually ended up doing it. 38:38 Getting over the reverence for Emacs's history
Sacha: Sometimes I am reluctant to suggest things because I figure Emacs is such a long history. Probably someone has thought of this already, and it's probably been discussed and bike-shedded. But I think there are little things that we can do. Philip: Yeah, but then in that case, Yeah, but I think that's actually related to another thing I wanted to talk about. There's a certain sort of reverence that people have for Emacs, because it's such a historical project. But I mean, the preset theme was something that was discussed for many times, and there were basically no objections. No one said, no, we shouldn't do this, this is a bad idea. I hope it's not only because I proposed it or something, or like the package also suggests that. Most of the things I've been working on for Emacs 31, no one objected to. And there's two sides to this. There's some people who actually go overboard with this and try and reinvent. Like when reviewing packages, you see this a lot of people try and reinvent functionality, which is basically just giving a new name Combining two things and giving it a new name which isn't always necessary but might be useful and then it's some discussion like can we actually make more out of this and that's a different thing but then there's the people who I probably lean more towards that side when I think to myself the way I'm doing this is stupid or this is not as efficient people have been using Emacs for 40 years of course there probably has to be a better way to do this 40:11 Changes are more likely to happen when someone puts in the work to make a patch
Philip: And sometimes it turns out it simply hasn't been implemented and no one has simply done this actually small effort of preparing a patch and ironing out the details just some people don't like discussions of course and it's understandable but you can I mean there's really no harm in sending a patch and then saying I'm sorry I don't have It's annoying, of course, from a maintainer's perspective. I don't recommend doing it, because if you prepare a patch but don't have the time to finish it up, then if it's a useful thing and you actually get someone to be interested in maintaining it, then bringing the patch to completion, then it's well worth just sending a feature. Even sending a feature request, you don't even have to... I mentioned the idea of this preset theme many times. I wish people would be more conscious of this mentality, but I totally understand people who think otherwise, because when the first time I sent a patch to a mailing list, I was, I don't want to say I was sweaty, but I was really nervous because I don't know what if they... Goodwill, good faith, attention to how people should behave on mailing lists, how they should treat each other. Lots of these preconceptions turn out to be false in there. That's why I also wanted to participate in this, so that people see, oh, the people maintaining Emacs aren't wizards locked up in a tower, but just, I hope, normal people. Yeah, that's a very good point. Prot: And I think, Philip, just to add to this, your example of leading with a patch, I think, is also key here for someone who can write a patch, of course, because it cuts out a lot of that noise, that initial discussion of, well, maybe yes, maybe no, because it frames minds. It focuses the attention on something concrete. And that can also... Yeah. Philip: Yeah. And... I mean, having a patch is useful, but getting someone interested is also helpful. Like the discussion when we merged which-key, I helped with that process. And I'm not, I think it was, I don't remember his last name, Jeremy, who actually did most of the work. And I was reviewing his patches. I was helping along, but I wasn't actually writing most of the code. I was just going over the proposals and helping along and basically pushing the... Stunning the process whenever it got stuck so that we actually made the necessary changes for it to get merged. 44:03 Preserving Git history of packages absorbed into the core
Philip: And then I did the last finishing touches of merging, because that was also something... Every time... We'd like to preserve the Git history of packages we merge upstream, which is probably something we won't be doing in that way when we do the Fat Emacs releases. But the entire history of Eglot and the entire history of which-key is actually preserved in the Prot: So they are wizards after all. Philip: Wizards just reading pre-written down spells. Sacha: It'll be interesting to see if some of the starter kits move to using that kind of fat Emacs infrastructure once that's in place. Because a lot of times the starter kits are there to package together. Okay, here's a list of the packages that it uses. Here's the configuration that makes them play nice together. And then here's some kind of Documentation or videos or a demonstration on how to use it to help people get started. Philip: So I'm curious to see, I mean, I went reviewing the options to add to the preset theme. I actually went through a number of these starter kits to see the options they suggested. Selected those out which seemed reasonable to me. And of course, this was discussed and people objected or added other things. But I am curious to see how the starter kits will evolve in the future, because that's also something we should mention. 46:00 Dealing with multiple types of Emacs
Philip: I mean, there is a big problem with the fat Emacs approach and suddenly you have two versions of Emacs. You can write a package which appears to work fine in fat Emacs, but it depends on a package which is not in the core Emacs release, and then that's something we will have to deal with in the future as well. Yeah, that's a tricky part indeed. Yeah, but another thing relating... Yeah, the sort of fragmentation of what core Emacs is. It might be a showstopper, so maybe everything I'm telling here is just a wishlist. It doesn't end up actualizing. And that fragmentation of the setup is one of the things... Because it's not actually really difficult to solve. I mean, if you have a package that depends on something from Fat Emacs who just added to the package requires lines, you explicitly state the dependency. But if people are sloppy, then they might not notice this immediately. And you have runtime issues when people are slow. Sacha: It's a little bit more than that, right? So for example, if you have a newbie asking a question, because they're using a starter kit or in the future, a fat Emacs thing with different packages installed and different configuration things that they have not personally set up. And they don't have the experience to know, oh yeah, this is going to be related to that. So I should mention it in the help message. I mean, large starter communities like, like Doom Emacs and Spacemacs will have their own Discord or mailing list where people can go and ask for help. And so people will say, okay, I think I kind of know which starting point you're coming from because it's the base. But if we're, you know, with the smaller starter kits, they don't even know how to ask for help. And everyone is like, on the regular Emacs communities, there's a lot of back and forth if you want to dig into, okay, what do you have enabled? What is affecting your setup? Fat Emacs is going to run into that problem. 48:09 Fat Emacs is just about bundling more packages from ELPA, not changing the configuration for them
Philip: To be fair, my understanding currently is that it wouldn't enable any other options. It would just bundle more packages. Sacha: I see. Philip: So it would be more of an issue for package authors. Yeah, for package options. The idea is, I mean, I've used Emacs in offline settings where it's like, really inconvenient or impossible to install additional packages and just having more functionality out of the box which ELPA provides and you don't have to install additionally, is basically the idea. Because this has been a project which has been ongoing for years. I think this is ever since the conception of ELPA itself. Which is precisely the reason why GNU ELPA requires all packages to be signed or to be covered by the copyright assignments while NonGNU ELPA does not. So that this is possible. It's just that finally it looks like we're starting to move somewhere in that direction. It would be interesting if a decision were to be made that we're going to give up on This sort of bundling, what decisions that were made for the legal status of GNU ELPA, if we would merge GNU ELPA and NonGNU ELPA together, which is unlikely currently. This is just pure speculation at this point, but it's something that might be a discussion, which will be had in the future. Sacha: Okay, so it dispenses with a package install part, and so people don't have to worry about, okay, how do I make sure The package archives are set up, and how do I install the packages? All that stuff will be pre-installed. The automated English will be- No, the package archives- Oh, sorry, go ahead. Philip: The package archives wouldn't matter that much, since we are just talking about the new alpha packages, which are installed by default. It's really just that you don't have to install additional packages. You don't need a network connection. You don't need to know about the package existence. It would be registered in the auto mode alist anyway. So if you open a, I don't know, what's the package, some major mode that's not going to open, which is not in the core. Prot: I think you might want to talk earlier. I think that would qualify. I think you mentioned org-tex earlier, which is on ELPA, but not in Core. Philip: The tricky thing there is that Emacs already has a LaTeX mode by default, and that already applies, but org-tex extends it. That's why I was looking for another example. Okay, that's the idea, but it wouldn't only be major modes, I assume. There's going to be some discussion as to what packages we want to add. currently it's not certain. Because we're working on finishing up Emacs 31. That's where most of the bug fixing efforts are going in right now before we progress to any further developments. But that also includes proposals. That includes proposals as to the preset theme, which I am still interested in reading. 51:23 Customize
Sacha: I want to come back to something Prot mentioned in my conversation with him about newcomers, and that is the Customize interface versus getting people to the Emacs Lisp directly. And I think, Prot, you were not very keen on Customize. Prot: Yeah, basically if I say it in one sentence is I think the earlier they get into Emacs Lisp, like seeing it and interacting with it, the better it is for them long term. Granted, I am making the assumption that this is a user that will be there long term, right? Philip: Of course. And this is specifically about the customized UI, right? Prot: Yeah, yeah, not the underlying functionality, like, yeah. Sacha: It's great for simple options like yes we can check the checkbox or we can select from the drop-down list or whatever but browsing it is as you mentioned overwhelming the general sense of Emacs being overwhelming and when you start wanting to do something slightly more sophisticated like You know, let's add some more capture templates. Then it's challenging for people to do. So I'm wondering whether, in general, we should be, you know, is our general strategy to be guiding people to, yes, Customize is there, but really you want to be doing Emacs Lisp as quickly as possible. Let's make it easier for you to get your init file. Let's make it easier for you to test your init file and not fall apart when you miss a parenthesis and all things like that. Do we want to guide people that way? Philip: One question I think we should distinguish is the idea of a UI the problem or is it really... Because I personally I have a new Emacs configuration at my day job, and I do everything using Customize. I don't even care about using use-package or whatever. Just customize the stuff using... There's a big blob of user options which I've modified, and that goes through, and I don't care about it, but I claim to have some understanding of what's going on, and the rest of the function is just some defuns which I find convenient. But for me, it's okay, because I have some sort of intuition of how the Customize UI works. If there were a better UI for Customize, would you still say that if it were written in an intuitive way, say using Fido modes. So that's, it would use interactive narrowing and it would somehow work in a build on existing intuitions because the current customized, the Customize UI, the easy customization interface I think is a technical term to use is based around this widget library interface and sort of make replicating a TUI menu but not... And then you have to... And yeah, of course, the intuition... Like, if you click on things, it doesn't always behave the same thing you would expect from a regular settings menu, which is by the way also something that CUA specifies. 54:41 CUA - Common User Access
Philip: I recently looked into what CUA lists. Like, if you look at the Wikipedia page, CUA specifies that every application has to have these settings menu with tabs on the bottom on the top where it lists all the options you can specify and interestingly C-c and C-v is not listed as... 55:00 ini file format? https://sdf.org/~pkal//blog/emacs/ini-init.html
Philip: Apparently not CUA, but Shift Insert and Control Insert... I might be misunderstanding this, but this seems to be a misnomer. 55:10 Emacs configuration generator
Philip: But if we had some sort of a UI like this CUA configuration UI, would that be something where you'd say as an intermediate stage for just setting options? Because that was part of my thought process with Emacs Configuration Generator. Just configuring Emacs is such a subset of Lisp as it's actually not programming Lisp. You can easily get by by just using add-hook, set up or setq, and add to list or stuff like that. But you don't really have to understand. It's just a peculiar syntax for how to program Lisp. 55:54 INI-style configuration
Philip: I'm not sure if either of you have seen, I wrote a blog post last March, no, not March, what's the name of the month? November, October or something, where I gave a prototype for a INI-like configuration syntax. Prot: I must have read it, but I don't remember it. You must have read it. Yeah, yeah, yeah, because I always read my feeds, but now it doesn't ring a bell. Philip: Exactly. You see there's this basically a simplified syntax, which should be... The idea was it should follow a conventional configuration-like format, and each of these lines gets translated directly to an Emacs Lisp expression. And due to this, I don't want to call it an isomorphism, but the easy translation in both directions, I think that the expectation of saying write Emacs Lisp... There has to be some defun or something if you're writing Emacs Lisp. That's to exaggerate. If you're just writing setq, set, add-hook, add-to-list, these common configuration patterns, which are well worth documenting in the manual, to understand what are the patterns that you have to use to configure a package, even understanding the signature... The distinction between add-to-list and add-hook is that hooks are lists which can have mode-local extensions but also inherit from global settings. Not obvious from the beginning to everyone. This is not list programming. Prot: Yeah, fair enough. Though even then, they start to see the parentheses, get used to the syntax. They have to remember to quote stuff. Even though it's not really programming, I see what you're saying. They put themselves in the situation. Philip: One of the ideas precisely in the config syntax is that if you have an option like set, you see the first line, set mode line compact long. Long is a symbol. I just use regular read to read this, and it's not evaluated. There's an option down there somewhere, I think, eval set, where the format expression is an S expression that's evaluated to a string. So you have to opt into evaluation. which seems more intuitive to me for a regular configuration when you're writing it, because all these things... Like, I have to think about quoting. Then there's the issue like with with-eval-after-load... Can I customize this variable before the package is loaded, after the package is loaded? If it has, like... If you're adding something to a list and the list has a default value that you don't want to set the value of the default, don't want to add it to the list because then it's not loaded, and it could trigger a undefined variable signal. So these are other inconveniences that I don't, I personally do not see any value in teaching people or having people to deal with these sorts of issues before they have any broader intuition. Which is a very idiosyncratic take perhaps, but... Prot: No, no, it's fair. Philip: What I'm trying to get at is this sort of any configuration syntax would be something that a UI could generate a lot easier and in a way that wouldn't have this artificial split between your own personal handcrafted configuration and the generated part of the configuration. Mechanically changing this, finding the section package avy, because it has all of these primitives which didn't exist early on in Emacs, like packages and features exist and so on. The sort of structure which use-package usually provides. Sacha: I have about one minute before the kiddo starts on lunch break, so I'm going to interrupt a little bit and do a quick summary. But the two of you are welcome to keep hanging out and chatting. I'll leave the Big Blue Button room open. And if you want, I can set it up so people can join you, depending on your time, et cetera, et cetera. 1:00:21 Quick summary
Sacha: But basically, what I'm getting for a quick summary of the conversation: Emacs 31: the newcomer presets is work in progress. People are definitely open to improvements, ideas, other suggestions for other features. The kiddo is just running out now. I will put the chat in the thing. Prot: Yeah, of course, of course. That's fun. So, what's happened? Sacha: Do you want me to open up the chat to everybody? Or do you have other things? Prot: Me, I can stay for another 20 minutes. Just to say I can stay for another 20 minutes because then I have to take the dog. Sacha: Yeah, and Phil? Oh, you have to leave. Philip: 20 minutes is fine. 20 minutes is fine for me as well. Sacha: Okay, okay. I will put the thing in the chat and people can continue because the kiddo was like, ah! Okay, yes. Prot: Okay, okay, okay. Good. So, yeah, of course, there is a chat going. Yeah, let's see. So, Sacha, you will link it there. Ah, nice. Philip: So, I presume there has been an idea of people watching this. Prot: So this is live. Sacha: And I can copy the chat thus far since we didn't even get to any other questions. Hang on a second. Where am I even? Prot: We're trying to deal with those, right? Yeah, yeah, yeah. Well, eventually to have a discussion and also take questions, eventually you need to have more time, I guess. Sacha: Yeah, yeah. Prot: But thank you all so much. Yeah, yeah, yeah. That's good. Yeah, yeah. Thank you, Sacha. Thank you very much. And of course, the kiddo overrides all. 1:02:27 Continuing with INI
Prot: That thing with the INI, I think it's very promising. I mean, if you flesh that out. Because the other thing is, yeah, yeah, with the INI configuration, because what would be, though, the fate of what is now added, you know, when you modify something and it adds this, you know, this has been set by custom, do not touch it kind of thing. You know what I'm talking about, right? Philip: Yeah, you mean the generated user glob. Well, my idea, or if I were, if I had the time /motivation/whatever to flesh this out, because currently it works... Currently it's an actually existing Elisp file which you could use, but I think it would be most interesting if it would be upstreamed. It would sort of be like, if you don't have a .el file, Emacs would look for it .ini file, or emacs.ini file or something like that. Then, of course, you can check, like, does the INI file exist or does the .el file exist? Probably there would be a user option to select into which it would inject the new options. And by default, it would select, for example, if the INI file exists, then it would use the INI file. But there is some controversy to this, because I totally understand the sentiment we're coming from with... You're using Emacs, so you have to learn Lisp. But for me, the bar is a bit higher than just the inconvenience of writing out this more or less. It's, as Joel Sussman referred to it, this ritualistic Lisp. You always have to repeat the same stuff all over again, like with eval, afterload, set. add-to-list, then you have to quote the option in one case. And if you change something in a map, then you don't have to add it. And of course, if you know Lisp, then you know that in one case, a keymap is a cons cell, so you're actually modifying the rest of the cons cell. That's why you don't need to quote it. But in the other case, you're accessing it via symbols, so you need to quote it. But this is all technical details. There's no necessity in it. It doesn't have to be that way. Prot: Yeah, yeah, yeah, that's fair, that's fair, of course. 1:04:42 Motivation
Philip: One thing I wanted to bring up in the discussion when we were talking about reverence was there is, I mean, one part of the thing that gave me the motivation to go through with learning Emacs, even though I didn't use the tutorial initially, was sort of a reputation I heard about Emacs. And the videos I saw, wow, you can do these cool things. And this motivation, this image I had of Emacs help me go through, but if you overshoot this approach, then people expect too much in the beginning and are disappointed in the end and don't pull through. There's this question of having, how's it called, the ??... How to motivate people enough to be interested in Emacs, to actually learn it, but not to oversell it. If you give some sort of a demo of using Emacs, which is simply not representative of how it actually works, then that's something which would backfire. But I guess we can take a look at the questions, right? Yeah, let's see. Let's see. Prot: Yeah, yeah, yeah. So yeah, I didn't read them. Philip: I had the chat open, but I didn't have the time to read them. Sorry? I'm not sure how to parse these. Is this from top to bottom? Prot: I guess from top to bottom is how they arrived in the chat. The top is the earliest. Philip: The usernames are mentioned below. Prot: I guess that's a copy-paste thing. Yeah, yeah, yeah. So there are some... Sacha: I gave the kiddo some packed lunch, so I'm back. Prot: Oh, hello there! Philip: We were just wondering about how to read the comments you posted. Maybe you have a better UI. Sacha: I pasted them into the chat. So in the Big Blue Button... Philip: But that's the order of occurrence? Sacha: That's order of occurrence. It's totally not very... It's just like a big paste. 1:06:50 Politics and philosophy
Prot: While you read it, let me... Yeah, there is a comment there from LC2000 about the splash screen having a lot of emphasis on the legal side, which is a fair comment. I think the legal side is important though, because of course, free software and all that, but of course, it could be rearranged. So maybe you don't want to have it at the top front and center, you want to have it further down. Maybe. I don't know. I don't have a strong opinion, but I think the legal side is it should be there at some point. I feel like it's a political minefield though. Sacha: Just leave that alone. 200 comments on emacs-devel. One of those really long threads. Philip: I cannot under-emphasize how surprised I was when my suggestion to add a checkbox on the splash screen just went through. Because I expected people to object, no, we can't add it there because of some system. It wouldn't look the way it should look and that would be confusing or whatever. But apparently change is possible. You have to be careful and be patient. Prot: And I guess here there is an assumption, right? There is also an assumption that people will attack you or be unreasonable. And I think this is not true. You mentioned it earlier as well. Eventually you have to get on the mailing list because people, if they don't hear the opinion, the counterpoint, they will never know what to do with it. Philip: but it's not entirely unreasonable because there are discussions that can be... There are people on emacs-devel, it's sad to admit it, but there are people who voice strong opinions, like strong opinions, with no power behind them, which can scare people away because there's no... There are no tags. There's no index of people on emacs-devel, so you don't know if some John Doe responding to your message, if he's actually responsible for this and makes ae decision, or if it's if Eli is sending a message and his decision on the discussion actually weighs a lot more than other matters. 1:09:23 Experimenting with things outside core
Sacha: I feel like sometimes experimenting with newbie-focused resources, like the unofficial ones that are around... At least we can try the ideas out and then say, hey, here's the patch and also here's what people have been using it for, so you can see it a bit more concretely, than dropping an idea into the discussion and then having the whole bike-shedding happening without as much data. Philip: That's seriously my main recommendation. If you want to propose something, add a prototype, add a patch, add something to narrow down the discussion. That's something people would take away from this discussion, from my experience. Prot: I 100% agree. I think that's the way to go. Just implement something so that it focuses the attention. Otherwise, you will get those endless discussions very quickly. Sacha: Or try it as a package first, and then it can be core. Philip: Excuse me? Sacha: Oh, I was thinking if it's possible to prototype something as a package, now that Emacs has made it a lot easier for people to install packages, then at least it can be tested before having all the conversations about whether it should be as part of core or part of the splash screen or everything else. 1:10:42 Extending the core
Philip: The counter tendency I feel obliged to mention is that many times proposing something as a package or as an extension to the core can actually simplify the implementation vastly. Especially if you need to make one or two twists upstream and you need something like an additional hook or something to exist upstream. If it's a package in the core, then it's a lot easier to explain why you have to make this change than having to deal with some sort of advice and changing a lot of things. There was a certain tendency during the mid-2010s, which I only know from history, was to re-implement a lot of stuff in logs, in packages, instead of working on them upstream. That created a lot of divergence between packages, and in my opinion, complicated things because it introduces this entire choice fatigue. Should I use Flymake? Should I use Flycheck? Should I use LSP mode? Should I use Eglot? Which is not a historically accurate example in the stats that I'm given, But I'm certainly in favor of at least considering upstream contributions. 1:11:52 Guide to contributing to ELPA
Philip: Even like packages, of course, it's the way we recently published these guidelines, or not guidelines, this contribution guide to publishing packages on ELPA, which is on, if you want to open it in the browser, it's on the ELPA homepage, which lists sort of these hard criteria which we require from ELPA. Just elpa.gnu.org, yeah, it's... That's going to be a link to the page. Sacha: Yeah, this is pretty recent. Philip: This is recent, and then there's a list of suggestions. But this is getting off the actual point. I'm just saying that relating to the general point, my experience is that proposing something concrete but also be open to hearing the opinions of other people These are the two necessary but maybe not always sufficient ingredients to making the changing stuff. Because if you just say, I want this to be different but don't put in the work, then everyone's going to forget it. But if you propose something and then insist that it has to be exactly this way, then you're just creating social tension. Maybe missing out on interesting things. 1:13:11 Making the newcomer experience better
Sacha: And especially since people are using Emacs for so many different reasons and coming from so many different backgrounds, what you are very firmly committed to might very well work for one set of people, but will run into these issues for all these other people. So if we want to bring it back to this, you know, how do we make the newcomer experience better? It's great that in core, there's starting to be a little bit more infrastructure for supporting things like sets of reasonable defaults for people. And maybe we as a community need to figure out, all right, how do we write documentation around it? How do we make tutorial videos? How do we encapsulate, okay, this is what this typical newcomer experience is like for this set of people and maybe these options or packages or a glue code might be helpful for this group? Maybe. Prot: Maybe. Yeah like in theory you can imagine of something like if you are a Python developer, here is your Python presets theme. If you are doing Org or whatever, here is your LaTeX and friends, right, and you could also have extensions like that in the future. Philip: I mean nothing about the idea is... It could have been used as a package people can load otherwise. 1:14:30 "user option themes" versus "appearance themes"
Philip: And hopefully, as I said, there is certainly additional work which can be put in to support making user option themes better supported. I think one of the things that will be useful is actually referring to them just in nomenclature points as user option themes to distinguish them from. Sacha: From themes. Philip: From color themes, yeah. Color themes, yeah. We even introduced the distinction themes have kinds since like Emacs 20. 29, I think. 29. Yeah, yeah, yeah. Prot: I think you did that, right? Philip: I think I worked on a patch. But that was exactly, I mean, that was already where the seeds for the current theme were started, because we wanted to distinguish between these different kinds of things. Were there any other questions? Prot: I don't think so. But yeah, as we saw now with the find-library that Sacha did in the beginning, it would be nice to also eventually be able to find the theme or whatever. Maybe it's a different find-theme, if for whatever reason it cannot be find-library. Philip: That's actually no reason why that shouldn't be the case. I mean, you could just extend the logic to not only consider the load-list, but also the... Whatever the variable is for the list, then it should be able to find that as well, even though it's strictly speaking, that's a library. But that's a decision that someone has to make at some point or convince someone. Sacha: I think find-library does work for it. Like, find-library will find it only if it's loaded. And then since I can't, like, undo it... Prot: If it's a package. Sacha: Yeah, yeah. Prot: If you install it as a package, yes. Philip: Because then the theme is in a directory which package.el has added to a load list. I think the preset, if my memory serves me correct, then find library only looks through load-path. Sacha: I see, I see. And etc/themes is not in the load-path. Philip: Exactly. Because these aren't, this is, I don't know why. It's not... Sacha: Okay, all right. That's another message to emacs-devel. 1:16:49 configuration generator in Emacs? maybe more wizards?
Philip: It's the sort of annoyance which from my perspective is so inconvenient that I forget it every time and then you don't change it. 1:16:59 Starter kits
Sacha: @brongulus says the Doom Emacs module approach is very nice for beginners and entices them to get into things more. People interested in a certain common set of functionality can get an opinionated starting point in Emacs, rather than worrying about what to install. And someone else in the previous That's sort of like the theme approach, isn't it? Sort of, yeah. It's not just, hey, these are the packages and you can comment and uncomment lines that load the different modules, but also here's the glue to sort of start to make some of them work better together or to change them to reasonable defaults. 1:17:39 Configuration generator in Emacs Lisp?
Sacha: I was wondering, actually, along those lines, any thoughts about making your configuration generator type thing in Emacs? Philip: The reason I, in the configuration generator, did not implement it in Emacs was precisely due to if it were in Emacs and would use, for example, something like the widget library and there would be these fine UI discrepancies which people wouldn't expect to behave the way they do, then scrolling doesn't behave exactly the way they expect it to do. But there has been an idea, I think, when I mentioned the configuration generator the first time. It was the notion of having actually a shared file format behind it, just some S expression, which could be loaded by both the configuration generator and a generic configuration wizard, which could also be used like every package could define their own configuration wizard for asking the user selected options and configuring these. 1:18:40 extending the archive format
Philip: That's also another thing in Emacs 32 which I plan to work on, to extend the package archive format. Among other things, allowing for multiple packages to be listed in it, because GNU ELPA and NonGNU ELPA both store multiple versions of all packages, but you can only install the most recent one. That's why pinning doesn't work. Absolutely no technical reason why this shouldn't also list other versions as well. And then you could have pinning without having to use Git. Packages as well. And there are a few others. There was a thread I think earlier this year where I collected a number of these extensions for the archive formats which could be extended. And now I forgot my thread. Now I lost my thread of those. Prot: But basically extending package.el and the archive, yeah. Philip: Specifically the archive, so that Prot: Showing the previous versions which are already listed, like you said. Philip: Yeah, so that you could pin the version so you could install the version. I honestly do not remember what I was saying just a few seconds ago, which is embarrassing. Okay, that's another problem. Prot: Things happen, no worries. Philip: You were talking about Doom Emacs? Prot: There was a comment about the Doom Emacs and specifically the fact that there are these modules and you can load the module without thinking specifically about the packages. But then Sacha told you about your package configurator wizard. Philip: Package configurator wizard and then extending the metadata could also include this sort of configuration option. So that packages, in some sense, could specify what options the user would primarily be interested in and what order they should be traversed. And you could have some sort of dependency, of course. This is some effort which has to be put in, but it's not something that's unreasonable, from a technical perspective, from implementing this. And it would make, I think, it could make, if you have the infrastructure for that, that would make installing and using packages a lot nicer. It sounds very promising, for sure. 1:20:56 User interfaces
Philip: The UI question remains the thing. Do you want to reuse the Customize UI, which has its historical warts? Of course, can they be ironed out? That's a different question. Or do you reinvent something from scratch? And I'm usually not that big of a fan of reinventing the UI. I'm more in the reuse existing interfaces, just into the back end. Prot: Plus, if you were to invent a new UI, you wouldn't have this new feature already because you have too many things that you need to implement. Whereas just using custom UI allows you to just implement the feature and then the interface, maybe it's something that somebody else will work on or you work on at the latest. Philip: Yeah, but then, of course, that's... Even if that is the case, then you have to make sure that you don't make assumptions that depend on your own customizer in the future. It's a whole list of dependencies which is just complicated. Sacha: That sounds like a newcomers presets to un-wartify Customize, a reset theme to put the warts back on as needed, and then we can use the slightly more modern interface for the things that we had... Prot: I think just to say this, but of course everything we have covered thus far, always we have to state it. Newcomers with an asterisk, right? With the caveat that you still have to put in the work, read the manual, be patient, all that, right? Philip: Ideally, it would be nice if you could even start without it. I mean, I started without it, but it took me three or four years to actually write this one. I didn't want to write defun. I thought, what? I don't write my own functions. I just want to set options, which was wrong and appealing to this. That was the point from the beginning. But I think, Sacha, you wanted to close there. Sacha: Oh, I just wanted to acknowledge that we are coming up in the 20 minutes that you said you were available for. Yeah, yeah, yeah, I need to go. Yeah, yeah, the dogs and everything. Prot: Yeah, yeah, I have to take them for a walk because I have a meeting afterwards. Sacha: Right. I wanted to thank both of you. I really like this conversation and the heads up and the interesting things coming down the pipeline. So thank you for that. We're going to continue, I think, working on the user experience for newcomers. which will probably be a mix of documentation and packages and other experiments and occasional email to emacs-devel suggesting things like the find-user-init-file and whatever. But thank you so much to you and to everyone who's tuned in. Philip: You're welcome. Prot: Thank you. Thank you. Thank you. Philip: Take care. Prot: Take care. Bye-bye. Goodbye, goodbye. Where do we close from here? Philip: I'm just going to close the tab. Bye.
