# Building reproducible Emacs Andrew Tropin [[!template id=vid src="https://mirror.csclub.uwaterloo.ca/emacsconf/2020/emacsconf-2020--08-building-reproducible-emacs--andrew-tropin.webm" subtitles="/2020/subtitles/emacsconf-2020--08-building-reproducible-emacs--andrew-tropin.vtt"]] [Download compressed .webm video (18.4M)](https://mirror.csclub.uwaterloo.ca/emacsconf/2020/smaller/emacsconf-2020--08-building-reproducible-emacs--andrew-tropin--vp9-q56-video-original-audio.webm) [View transcript](#transcript) It's not always easy to take part of someone's configuration and make it work, it's almost never easy to move your configuration to fresh OS installation or hardware. Not sure that this snippet is enough to make package work? Forgot to install ripgrep in your system for rg.el? Got a broken version of package on package-install? There is a way to make an Emacs configuration reliable, composable and self-contained. It's possible to freeze package versions, create systemd unit for emacs daemon, maintain system dependencies and package subconfigurations in one place with one tool. The talk explains how to leverage the power of nix package manager and use-package to make pretty good emacs configuration. There is a stream record on the same topic: . It lacks few interesting points about composability of such configuration approach, but already have enough interesting information. The talk will be a little more structured and more Emacs-users oriented. - Actual start and end time (EST): Start: 2020-11-28T11.26.34; Q&A: 2020-11-28T11.40.48; End 2020-11-28T11.43.33 # Questions ## Do you deal with config files such as emacs-custom.el, some which have sensitive data? Sensitive data is in other directories that aren't shared, and emacs-custom.el is completely avoided, as it prevents reproducible/system independent behaviour. ## How did you learn Nix language basics? Just from the the manual? He referred to the Nix IRC channel. ## What are the main advantages besides switching computers (which most people rarely do)? Make parts of config available for projects - sharing with other people. ## Have you tried Guix in place of Nix? (more parens! :) :) Currently trying it, and also in-process of switching from Nix to Guix. # Notes - Emacs configuration is entangled with the system configuration (dired uses ls, grep.el uses grep). - Reproducible behaviour is therefore not only dependent of Emacs compilation/configuration, but also system configuration. - "config.el" files configure Emacs, and accompanying "default.nix" files make sure that the correct packages/fonts/libraries/etc are installed. - Reproducible development environment: - Using Org-roam to demo how to config a Nix layer(?) - custom.el conflicts with Nix(?) # Transcript 00:00:00.399 --> 00:00:36.399 My name is Corwin Brust and I will be talking about getting started with Emacs today. I have been an Emacs user for a long time. First of all, thanks and a huge welcome to the conference from me and and on behalf and back to the other people that have been helping to organize. It's been amazing just to be involved with that and just, kind of, see backstage. 00:00:36.399 --> 00:01:33.759 So I've used a lot of different editors in my time. That's about 25 years as a professional software engineer. And most of that time I've been using Emacs. I'll talk a little bit in a minute (if I can ever find my slides) about how I got into Emacs, but I think if you've used Emacs and a lot of other editors for a long time, something that you notice right away is that you get good with it in a way that stays meaningful. You learn new things. Those things stick with you. You learn how to make it do new tricks and then keep doing those tricks. 00:01:33.759 --> 00:02:17.200 I want to mention that this conference--oops, this talk isn't about how to adjust your configuration specifically. I don't have a bunch of good code samples in here. There are other great talks at the conference, particularly Andrew's, that I looked at, that looked like they might be more aimed at that "hey, I'm just getting started with Emacs, what are some things to try to make it more comfortable for me starting?" This is about how to think about the problem space. Hopefully, a good warm up as we start thinking about some of the lightning talks a little later on. 00:02:17.200 --> 00:02:29.680 I'm just gonna quickly make sure I can see my IRC buffer in case I run into time. I didn't get my stopwatch started for this one. So all right, let's dive in. 00:02:29.680 --> 00:02:53.519 We assume that we want to install packages and maybe configure some features. This is particularly from the perspective of where we're working with a bunch of people on a team and we want to get something done. Some of us probably already have mature Emacs workflows. Others are installing it for the first time. 00:02:53.519 --> 00:03:35.840 So the first question is, you know, in that context: what's the value proposition? Why should I mess with my machine, my mature Emacs configuration, and impose my ideas over the way somebody else is learning Emacs? Well, it can be.. I'm off my slides here a little bit. It can be a little bit tricky to learn Emacs. One thing that helps us a lot is if people that we're working with can tell us, kinda, keystroke for keystroke at times, what to do and explain what everything is doing. Using the same packages can really help us working together on a project. 00:03:35.840 --> 00:04:54.840 Speaking from my personal experience, it took me decades to get to the point where I was excited to program in Emacs Lisp. I've programmed in a lot of programming languages, but Lisp wasn't on my list. I looked at my config that I was copy-pasting around from generation after generation of .emacs file or recrafting it from hand and from Internet searches, to get the things that I needed when I would quickly go install Emacs at some new job or contract, and be able to to quickly get through that workflow that caused me to install the program. You know, just little simple one-liners that that got committed to memory over decades eventually just led me to a sort of "hey what's going on here." And I credit Jeff Goff, my good friend who died earlier in 2020, for my lifelong love of Emacs. Perhaps EriK and I will talk about that a little bit more in another talk we have scheduled, but Jeff was a huge influence on us in a number of ways and a huge contributor to the Raku programming language which is very cool. 00:04:54.840 --> 00:06:23.380 So, understanding how to make a good decision about splitting up configuration in a way to share it across people with really different uses of Emacs... That's actually a complicated topic and I want to sort of back off and stare at it for a second. I think Emacs is about people, so that means it's about community. And community means we're going to invite disagreement. In fact, that disagreement isn't necessarily a road-block to our project. In fact, some of the work that a community project can invite us to do is to get closer to each other by inviting those disagreements, by learning from them--learning from different people's styles and from how they argue, and thinking about why they have that perspective and what technical benefits that perhaps radical point of view might carry away. Some people are really aggressive arguers, and others are very passive and really couch their ideas in distancing terms, to say, "well probably, this is a good idea" or "please double check me." Those don't always necessarily indicate how certain a person is, because we're different. We have different ways of communicating ideas like certainty or excitement. 00:06:24.560 --> 00:07:29.039 When we think about a bunch of really diverse programmers approaching Emacs, probably one of our our first really big challenges is just to pick what we're going to go after. There are a lot of existing kit installs and things like this. My argument is that you could actually get pretty far just trading files around. Maybe the more valuable conversation to have is making the hard decisions about, well, "should we have vertical completion," should that be the out of the box, and the people that want the traditional splayed out over a single line completion for example in the mode line, those people are going to add a line of config to their own setup? 00:07:29.039 --> 00:08:16.240 The way to get there? I mean, how do we find out what works? We don't want to slow down the people that are super productive with Emacs by asking them to completely break their workflows and make it easier for new folks. At the same time, we do want to make sure those new people are excited by Emacs and not turned off by having to learn the entire jungle of Emacs history in the form of its unique technical stylings for things like frames, buffers, and other unique Emacs viewpoints on important interface concepts, especially. 00:08:16.240 --> 00:09:04.800 The encouragement here is to keep the initialization for a project team together as a crucible. Rather than necessarily following our defaults of finding the simplest configuration that generally work and letting people customize it, what if we tried to look for fairly specific configurations that we'll expect essentially all of our developers to be using, at least when they submit bug reports. In particular, with this, I think that degree of experimentation can drive back into the Emacs development process. In the development mailing list... 00:09:04.800 --> 00:09:15.120 I'm hoping I'll get a timing cue here. 00:09:15.120 --> 00:09:50.720 In the context of Emacs development as a greater entity, we see some of these struggles. Should we change this default? Sometimes we can have the sense that defaults in Emacs will never change. The conversation is too difficult. I think one thing that can help us get there is evidence that says, "hey my 30- to 40-person project is using this set of bindings and here's what we learned about brand new Emacs users trying to come in and get work done with that." (Amin: Yeah you still have a couple more minutes) 00:09:50.720 --> 00:10:02.000 Oh, beautiful. Okay, great. I will try to get through my last few slides that i cut in my last walkthrough, but I think i'm going quicker today, thank you. Thank you. 00:10:02.000 --> 00:10:43.040 So let's just recap real quick: in theory, Emacs works out of the box. That means we're free to experiment. We can throw it all away and start over. As an organizational principle... I don't know what I was thinking on that slide, excuse me. Bringing it back around to the free and open source software community, our goal is to enable users to unlock their computers, to do as much with them as possible. 00:10:43.040 --> 00:10:57.920 That's the context to take with project initialization, but sometimes it could make sense to put some gloves on. I've thrown up on the screen here just a couple of other ideas, ways to maybe think outside of the box. 00:10:57.920 --> 00:11:29.120 As you're putting together project nets, my words of encouragement are to experiment with it, try different things, and think really specifically about how different the development users might be from each other as you define standards for configuring the user environment of Emacs specifically for developing on a project. That's pretty much my talk. 00:11:29.120 --> 00:11:32.959 If there's any time, I would take a couple questions. 00:11:32.959 --> 00:11:53.839 (Amin: Thank you for your awesome talk, Corwin. I think we have one or two minutes for a few questions. Do you have the pad open or would you like me to read the questions for you?) 00:11:53.839 --> 00:12:03.519 Oh, I managed to close the pad and I am trying to open it again. All right, there it opened. 00:12:03.519 --> 00:12:09.360 Bringing it onto a screen where I can see it. Will you read me the first question while I drag windows around, please? 00:12:09.360 --> 00:12:15.600 (Amin: Sure. It says, "do you use Emacs as a community building tool?") 00:12:15.600 --> 00:12:19.760 Do I use Emacs as a community building tool, or how do I? 00:12:19.760 --> 00:12:22.182 (Amin: It just says do you.) 00:12:22.182 --> 00:13:14.639 Yes, absolutely. I think Emacs is an ambassador to the GNU tool chain. I think that in the fullness of time, we will see an Emacs that makes and that makes iOS and Android and other closed-source tools dream. That's why they mock us and call Emacs an operating system. It's because it could be, if we cared for it to be. It's quite a threatening product from the perspective of how many problem spaces it can address, how many types of users it can satisfy, the things that we can do to make it robust in those environments. I mean, we're always thinking about the weak points, but is Emacs a community building tool? Heck yeah. 00:13:14.639 --> 00:13:26.880 (Amin: There's like one or two more questions. I think they're more long-form so it might be better if you took them off stream so you could keep the schedule on time.) 00:13:26.880 --> 00:13:33.360 I would love to take those questions offline. I will respond to you in writing if we don't get to it in a breakout room. 00:13:33.360 --> 00:13:38.000 Thanks so much for joining us. I can't wait to see the rest of the conference. See you there! 00:13:38.000 --> 00:13:42.800 (Amin: Awesome. Thank you again so much, Corwin.)