0:01: Intro: Sacha: Fantastic, this is great, I finally get to talk to you. I appreciate that you blogged so quickly about some of the things that I mentioned, and we can certainly dive right into that, or you have a lot more experience with how these conversations go, so I can let you take the lead.

Prot: Since you put in the effort to write, we already have a very good structure. The idea is, let's have your screen, so you can share your screen with Jitsi.

Sacha: Yeah. I will share my screen.

Prot: And we can go right into it. Let's see. So if you hover over… Okay, yeah, you have it.

Sacha: yeah oh you know if if at some point I should be really like fancy… Future session, we should get crdt working because that's fun.

Prot: Ah, yes. Oh, that would be nice. Yes.

Sacha: Yeah, that would be nice. All right.

0:50: Organizing my config into multiple modules and org-babel-post-tangle-hook: Sacha: So I've been making good progress in splitting up my config into multiple modules. I just have to iron out a couple of things like do I actually have to load the autoloads from the user list directory or does it automatically take care of that? Because sometimes it doesn't seem like it's doing the thing. Anyway. It's making good progress. And in fact, I came across something that I'm not sure you know about yet, or maybe you know about it and you decided not to do it. I found out that, so, okay, so here's the context. You know, when you do your literate config, you have your modules and they're actually just one big file, like one big source block with a commentary and everything in it. Yeah, yeah. So I found out that you can use a hook if you want to, to add stuff to the tangled files afterwards. So the way I set it up with my config is I still want all the different functions scattered all over the place because I'm not yet as organized as you in terms of the modules. So the org-babel-post-tangle-hook here, post. Yeah, yeah, yeah, post

Prot: So what did you do with that? Let's see.

Sacha: and boilerplate… has that boilerplate here we go so what it's what this does is when it tangles it it then goes back into the file and it inserts all that extra text and the footer into the tangled files so I still have my links to

Prot: Nice.

Sacha: the different source files where it comes from. So this is the section where it comes from but I also have all the extra lovely commentary and stuff so I'm like…

Prot: Ah, that's smart. That's good. That's good. Yes.

Sacha: That way, you don't have to keep repeating things. Although I guess if you really wanted to repeat things you could you could theoretically have the license just as a no web reference and then have it go in there automatically. anyway so I thought that was really cool so I'm making progress on the things that I had mentioned in the in the blog post about organizing my config into multiple modules and other yeah…

Prot: And how far are you in that project? How far are you?

Sacha: Let me see. I can look at the sacha.el here and I can do an occur on the files that have the lines that have the defun. I only have 482 defuns to get rid of. This is already a lot less than what I started with because like you, I have a very large… Almost 40,000 lines in this sacha.org.

Prot: Yeah, yeah, that's massive. Yeah.

Sacha: It's fun and it's interesting. It is a little reassuring to know that people still rely on your published modules instead of actually, like, do people take your config? I know you've got stuff in the config that makes it possible for people to just load it and add their customizations on top, but do you hear from a lot of people who do that?

Prot: From a few of them, yes. And this is why I actually created those customizations. But I must say, I have been trying to

Sacha: Yeah, yeah.

Prot: make it more difficult for them. So I used to have a use package, but now I disabled it on purpose and I have my own macros, so that somebody doesn't just copy-paste. And I don't do this to be mean, but I do it because this way somebody will have to think about, like, okay, what is this? What am I doing here?

Sacha: yeah I figure making making them still do that okay what am I doing here while still being able to automatically load all the function definitions will probably get them over that you know like make it a little bit easier for them so at least that way like right now it is difficult to copy things from my config like like you're so like okay maybe this is a feature but you know, maybe changing it will be nice.

4:45: Changing namespace, renaming functions: Sacha: The other big thing that I need to do with my config is I'm thinking about shifting everything to the sacha- namespace instead of the my- namespace, which is going to be a lot of renaming, which is actually, it was actually the question that I had about renaming things, not necessarily coming up with clever names that have good acronyms like you do. And I love that the humor that you have in there, but like, like just mechanically, are we talking wgrep is like, is there a more modern, emacs 31 way to rename things? Am I just using erefactor or like replace-regexp? What do you do when you need to rename a symbol in possibly multiple files?

Prot: If it's in multiple files, I do the grep approach. So it's not that sophisticated, but it works. Because the thing with the multiple files is, and it goes also to what you were telling me in that article, is first you organize, and then you refactor. It's that idea. The multiple files will not have a lot of extraneous information. You will not be matching, at least in theory, you will not be matching too many false positives.

Sacha: Yeah, and if you're doing a single file,

Prot: So you won't have to sort it.

Sacha: what do you like to do?

Prot: I have a package called substitute. One of the ways I do it is just substitute the symbol at point. But of course, this is just a minor convenience. You can do that with a query-replace. I'm not saying that you really need the package. But the idea is that you do it and you know that it works. Like, for me… I know that it works in the file. So for me, that's very reliable. But the other thing I should mention is keyboard macros from dired combined with substitute. So you start from a dired buffer, and you go file by file. That's the general idea. And in each file, you will perform, for example, a search to the symbol. Once you are on the symbol, you do the substitute-replace command, and then you move to the next file. So that is the workflow. And I do that a lot, for example, with my themes, because they have a lot of repetitive code, like each theme.

7:11: Defining aliases for old functions: Sacha: Okay, the other thing that I was thinking of as a workflow improvement here, because I'm sure that I'm going to keep calling them by their old names, especially interactively, like have a lot of commands that go off the meta x, my do this and this and this is I might also need to think about adding a function alias automatically. And one way I was thinking of doing that was just, you know, iterating over our array and bulk defining aliases so that all the sacha- stuff is now named my- stuff but I was wondering if that was a or actually also manually inserting the like well not of course manually but but creating forms for like defining the aliases somewhere but I was wondering if this was something that you already did as part of your workflow like do you when you rename things okay

Prot: No, I haven't. When I rename things for my packages, I do use aliases. But for my own code, if I rename it, basically, it's

Sacha: yeah yeah

Prot: just the latest name. So I don't try to keep aliases around. Because I eventually use a similar name, it won't be very different.

Sacha: huh all right yeah yeah I mean like it's it's there you

Prot: But what you said about the obarray makes perfect sense.

Sacha: might as well do do it automatically right okay all right that's me oh okay okay I can

8:30: Improving my streaming setup: Sacha: I can do my jitsi thing so I can see everyone and the screen at the same time the screen is very small okay so so that's I do have a dual monitor setup, which

Prot: Yeah, you need that dual monitor setup,

Sacha: is why I was like, OK, maybe I can start looking at your B-frame things. And in fact, in the minutes before I called, I figured out how to use MasterChat CLI to get the YouTube live chat into a command line program, which means that it can be run from call-process or make-process or other such wonderful things. So now it's an Emacs buffer. And then I was thinking, okay, maybe I'll make a pause frame or like a B-framed like dedicated frame for it so that I can have the chat of a live stream displayed within Emacs because you know, it's Emacs. We should do that. Yeah, yeah, yeah.

Prot: Nice. Yes, of course. And you can have it in a side window dedicated buffer.

Sacha: Although I might actually have to write my own like Node.js program so that I can also send text from it, from Emacs. I think the masterchat CLI, it only displays, but the library that it uses, if you pass it your browser cookie, you can use it to send messages back to chat as well. The reason I had liked Twitch before was because Twitch had some kind of IRC type thing that you could connect to. And then that meant, of course, that you can use ERC from within Emacs in order to send stuff to it. Anyway, live streaming and chatting, I've also been getting into that lately. And I was going to pick your brain about this whole like workflow for making videos or live streaming them. And more importantly, going back afterwards and remembering to post them or edit it, in case you forgot something or whatever. So if you happen to have any tips or the things that you like about your setup, I would love to hear about that.

Prot: Though in my case, the setup is really simple, and I admit that I could improve it. But it's really simple right now, where I have a wide monitor. So it's one display, I don't have two, but it's like 2500 pixels instead of 920. So I have a little sidebar on the side, and there on the sidebar I put OBS, for example, and I put everything I need there on the sidebar. And then I have enough space to have whatever it is I am displaying and maybe another widget on the side. So that is in terms of the physical layout of the monitor here. And then in terms of the Emacs side, I don't have a lot going on. I have one package to load the different font configuration. So when I do streaming or videos, I will load basically the presentation setup.

Sacha: It is a spontaneous.

Prot: That's Fontaine, exactly. But again, it's not a matter of the package. You could have a function that just changes the default phase, the height attribute.

Sacha: I have this monitor and then laptop, so this is my workaround for not having enough space in this desk for a super wide monitor. My husband has a super wide monitor which I like to borrow during EmacsConf. Hello child who is wonderful and likes to make cameos during my EmacsConf. Okay, I'm going to hug you.

Prot: Hello!

Sacha: Yes. So okay, so live streaming and then you just basically hop on the stream and talk about stuff.

12:09: Keeping things from accidentally airing: Sacha: I know you've mentioned things like just starting Emacs with your Scratch buffer, but yeah, how about the interesting workflows for not accidentally spilling secret stuff online?

Prot: Part of that is… so I use Vertico normally for my completions. I have some configurations for private Vertico, where by default, it doesn't display what Vertico normally displays. It's just a blank minibuffer, the way it is with the default Emacs minibuffer UI, right? But what happens is as soon as you do TAB or as soon as you move up and down, then it displays Vertico. So that, that is one way for me to make sure that I'm not showing anything I didn't want to show. The other thing is when I do videos, I don't use consult actually, even though I like it, because of the preview functionality. I don't want to be switching between files and then consult shows us something which is private. Right. So. So the private VertiCo, it's a small extension that I have with a few functions for Vertico.

Sacha: I've been thinking about modifying the console preview states so that I can elide more, I can skip over things that might be private. And things like, I already have a filter function for marginalia so that it doesn't show me the values of variables that might be private. But yeah, just turning off all these things makes it a little bit easier to say, okay, I'm just going to jump on the live stream and do this thing. Some of the other fun stuff that I've been doing along the

Prot: So there is that. And for private, of course, the other thing with privacy is that you want to have a generally good sense of where you put your files. So for example, in my pictures folder, I know that I don't have anything private there. But there are some sub folders which are like personal. So I know not to go there. So it might happen, I need to show a picture, okay, I just go to the pictures folder, and I show it, no problem.

Sacha: lines of keeping things organized is if I have a stream tag on a task, I know that's safe to show on screen. And then I modified my Org jump stuff. There's a hook that you can use to narrow things to just that subtree. So at least I can jump to it and not have to worry about the rest of the context in my inbox. Trying to slowly slowly get the hang of this

14:50: Livestreaming and recording: Sacha: Okay. So it's live stream. Do you like to live stream and record at the same time locally or just live stream and then go into the YouTube thing afterwards to download?

Prot: I just do the latter.

Sacha: It takes a little bit of a while,

Prot: I just download it from Youtube afterwards

Sacha: so I'm like… I could get started on the transcription.

15:09: Keeping track of interesting moments: Sacha: Do you have anything to keep track of interesting moments that you want to revisit, or do you just, I don't know, skip around in the video, look at the transcript, whatever?

Prot: I remember, I know this sounds bad, but I remember.

Sacha: People with good memories, boo!

Prot: And generally I try to also sharpen my memory. So whenever I can practice something, I will do it like that. But otherwise, if you really need to take a note of something, you can always have a small function that just records the timestamp. Like, what is the current time? And then you know when you started, so you will know where you are in the video. Like, it would be a very simple function that simply prints the current time, you know, format-time-string,

Sacha: Yeah. I just have to write something that gets the time

Prot: in a buffer at the bottom of a buffer. And that buffer is like your interesting moments kind of thing. And if you really want, you can make that prompt you for some text, like here is the timestamp and here is like, you know Prot said a joke or whatever, you know, like…

Sacha: started from YouTube and then calculates the offset automatically, so that I can say okay, here are my chapters roughly.

Prot: Yeah, that's even more fancy. Or you could do the other thing, which is all local, which is the moment the stream starts, you hit this command, like you invoke it, so it resets the time and then it performs the calculation locally. So you can do calculations with time in Emacs. So you can perform that as well.

Sacha: Yeah, that's really straightforward. Okay, so that's definitely something that I'm going to want to think about, because video is great for enthusiasm and showing cool stuff that you might otherwise forget to mention, but it's just so slow to review afterwards.

Prot: Yeah, of course, of course, of course. Just to say another thing with video, what I have found that is really helpful is to display line numbers.

Sacha: Oh yeah? Huh.

Prot: Me personally, I don't use line numbers, but I have found that when I am displaying something that others need to follow, line numbers help them. Because for example, earlier you were jumping around trying to find that hook, you were…

Sacha: Oh yeah, yeah, yeah. Okay. Display now.

Prot: And of course, me, I have experience, so I kind of know what you are doing, but somebody who is not really into it will be like, what is happening? Why are things moving up and down so quickly, right?

Sacha: Okay. And they can mention it, too, in the comments,

Prot: And they cannot track where you are.

Sacha: which is nice.

Prot: Yes, yes, of course. And also, when you are displaying something, you can say, look, on line 100, what I am doing, for example.

Sacha: I have to steal your config for the highlight line

Prot: And it's easy for everybody. Yeah.

Sacha: priority because I've been using the highlight line for that. But sometimes it overwrites things. I'm like, OK. Today it is well-behaved, so I'm glad for that.

18:19: Editing: Sacha: Making videos, all right. Just go ahead and make the videos, you just do it pretty straight, you don't do a lot of editing afterwards, I'm hearing, following the same kind of philosophy that you use for your blog posts?

Prot: That's the idea.

Sacha: All right, I should just go do things and not worry about whether the live stream demo that I just made of how I can highlight the PDF of your literate config and extract the stuff into whatever has a bug in it. And I'm like, oh, I just demonstrated that. It's okay, I can update it in the show notes. Oh, that's true, especially since

Prot: Or even better, you do a second video afterwards, a follow up.

Sacha: now I figured out that you can use org-pdfview view to link to pages in the PDF. So now my index.org has the highlights from your config, and it takes me back to the page that it was on. Very very cool stuff.

Prot: That's nice.

Sacha: Okay, so I just gotta do it.

Prot: I think Org-noter also is another package you could use for that.

Sacha: Yeah, probably. and then I just need to get… I think I've got PDF tools or PDF view set up. And then reader of course looks very interesting also. So I've got to tweak my config a little bit more to get it running because it has an external dependency. Anyway, so just got to do the live streaming. I was delighted. People have actually been dropping by and commenting or chatting during the live streams, which is great because I get to remember, oh yeah, I should explain that part, taking it for granted.

Prot: The thing with a live stream,

Sacha: So all of that is good stuff.

Prot: because it's something you also wrote, like getting used to talking to yourself, right? So, of course, that takes some practice, but I think, yeah, you have the hang of it already.

Sacha: Something is ringing. Hang on, sorry. I forgot. That was just my reminder that the kiddo is back to school. Virtual school is fine. Anyways, OK, so so just got to do it.

20:26: Writing: Sacha: Thank you for the tips. This is very helpful for

Prot: You're welcome.

Sacha: writing. I'm getting better at actually remembering to include more bits and pieces from my config, and I'm sure that now that I have them in different files, it'll be easier for me to then write the post that links to, oh yeah, here's the five other functions you need in order to make this little snippet work. But do you happen to, knowing the kinds of stuff that we like to write about, do you have any other tips from your workflow?

Prot: When it comes to sharing code like that, I already noticed while you were moving around that you have many things like my-consult, my-org, etc. What helps there is to just make those their own module right away. And from there, you know that, okay, this is either self-contained or it has an explicit require, so I can already know where I need to search for dependencies. So it's really that. It's because, for example, if you take just a my-consult function, right, of course, you know by the name that it depends on consult, but you don't know if it depends on my- common functions, for example. Right. Whereas if you have it in its own file, there will be a require at the top. So, you know, OK, require my-common-functions. And that way you can tell, okay, there is a dependency here. So then when you are to share this function, you can search for, okay, my-common-functions, is it mentioned here? Yes or no. And then you know what the dependency is.

Sacha: And I think this process of moving things into those separate files will make it easier for then, for people to say, okay, yes, I do want to try that thing. Let me check out the repository required, just load-file that particular file and then be off to the races. So we'll see how it works. I don't know if people actually… Sometimes people mention borrowing stuff from my blog. So maybe people are actually reading the non-Emacs News posts. We'll get to see that.

22:34: Packaging: Sacha: Sometimes I feel like a lot of my tweaks are very idiosyncratic, right?

Prot: Yes, what I found that has helped me is I implement the

Sacha: They're very suited to the particular need that I have. And then it's difficult to say, OK, if I were going to generalize this for other people, what kind of defcustoms will I need? What kind of options? And there's always that trade-off between, yeah, but I just want to implement the next little thing that I want to make for myself versus, well, if I put in the polishing effort, then possibly other people could use it, and learn from it, and then contribute their own ideas, and then everything gets better without me having to do the work myself. So it's a bit of a balance.

Prot: package that I want. So for example with denote, but this applies to everything, denote version 0.1 is the package that I wanted. So basically, it works for me. Ever since, I have been adding other things that people want, which are, of course, good things to have. They improve the package, but I have already been using the package that I want since the beginning. So ever since, it's just adding stuff and learning about how people use it and refining the code, which everybody benefits from. So whenever you have an idea that you are like, okay, this may be too idiosyncratic, don't worry about it. Make it into a package, and then what other people need will become apparent, and then over time it will change, but the core package is still what you want.

Sacha: Although it is interesting to see, for example, with the university calendar, institution-calendar thing, it's like, okay, you can get it to work for a small number of institutions, ELPA wants… they want it to work for everyone, everywhere, all the time. Okay, that might be too general. You might need to actually have lots of other people saying what they need in order to make that happen in the first place, right?

Prot: Which at that point, of course, what you want is to write the documentation. So for example, with the institution calendar, I wrote a couple of examples. Okay, how do you extend this? And yeah, I think that helps. But then of course, you cannot cover every use case like people have to also make contributions if they really care about.

Sacha: Yeah, so I think at the moment, I've been writing for n equals one, the audience is really just me. And occasionally I hear from people who are like, oh, that's an interesting idea, let me adapt it. Sometimes if I'm really lucky, they will go and write their own package on top of the stuff that I shared, which is the ideal situation, because then I can just like, oh, yeah, I'm going to borrow that and use it. It'll have more features and they're in charge of dealing with that. But I suppose at some point it behooves me to practice. OK, I'm just going to write it as a package, pretending that this is something, as you said, this is something that I want to be able to install and use myself. Then if other people find it useful, it's a lot easier for them to experiment with and then add on to.

25:40: Responding to email: Sacha: Which goes to my second thing. Doing this and making things open to other people probably means being more responsive to email. And this is, for me, this is a bit of a challenge. I'm starting to feel less time-starved, which is good. I'm starting to actually be able to schedule things. One of these days, we should probably see if we can schedule a Prot Asks thing. I don't know if I can do two hours, but maybe I can do one hour or whatever. Anyway, the rest of it involves actually doing

Prot: For sure.

Sacha: the responsible thing and responding to issues and emails and whatever. It's always a bit of a trade-off, like, oh, do I implement this other crazy idea I have, or do I answer my email?

Prot: For that, of course, it's a challenge. I must say that a lot of the maintenance work I do is via email. Or email or Signal or Telegram. People will ask me, hey, Prat, what is this? And many of the issues are not with my package. I had an issue earlier with the modus themes, no, the ef-themes, and eventually it was something to do with the user's configuration of some function of center tabs. But I had to go into it and check. So, of course, there will be that. But I must say, it's not too bad. It's not a big issue. You can always have in your email, like, hey, please don't use this for issues. And it's not a replacement for that. Just use the issue tracker.

Sacha: I know I just have to… I think I just have to like reframe my perspective. This is a gift. Other people are taking their time and effort to do this. It's wonderful that they're trying things out and putting their… actually doing things themselves and then reaching out in case… 'cause it would be nice to get things working on more people's computers. I think that the stuff that I've been building around learning languages and doing voice input into Emacs probably… There are a lot of these things already, but they tend to also be very individual workflows and individual setups. So it'll be interesting to get to the point where we can start to even have a conversation with shared code.

Prot: About the individual workflow, again, it's not a problem because what is individual now will eventually become kind of a standard workflow. Think about org, the beginning of org. You have Carsten Dominik, who is like, you know what, this outline mode isn't enough. I need more stuff on top. And eventually we have Org. In the beginning, I imagine org was basically Carsten's org, and it became this uh this package that everybody can use however they feel like.

Sacha: I used to maintain Planner Mode before Org Mode got super popular and I remember feeling very embarrassed when someone very, very kindly said "I appreciate the work that you do; incidentally, the latest update kind of deleted a lot of my notes." So this is like, when you make something that other people use, sometimes your mistakes will affect more people than just you. But I'm hoping now that now that the disks are in the spaces of terabytes instead of whatever, people are just backing up everything and version controlling everything and everything will be fine.

Prot: Yeah, of course, of course. Writing packages, of course, is a responsibility. The upside, though, is that because you know that it is a responsibility, you try to write cleaner code at the outset. Whereas if it's just for your own configuration, you're like, okay, this will work and I will fix it later.

29:59: Testing: Sacha: So I occasionally write ERT tests when I feel diligent. Sometimes I'm starting to write the test first and then write the code that makes a thing, but if you happen to have any parts of your workflow that you particularly like when it comes to testing things, I would love to hear about them because I haven't gotten to that part of your config yet

Prot: Yeah, so I don't have a lot going on for that. So it's simply ERT. But what I do with the tests is really basic. So ERT, M-x ert, and then I pick the test that I want. And I must say that when it comes to tests, I can be better myself. So there are some packages I write where they have good tests, but there are others that have zero tests. So I want to reach a point where everything has tests, but it takes a lot of work.

Sacha: Yeah. I mean, like every so often I feel like very, very diligent and I'm like, okay, let's do code coverage. So I can see things with undercover. Let's write a function and make sure there's a test associated with it. And let's write a keyboard shortcut that lets me jump from the thing to the test that's associated with it or to run it. And in fact, I still need to get embark to do all these things for me so I can be looking at a function and say just rerun the test for this, please.

Prot: Just to say one low-tech feature that has helped me a lot, low-tech, Is i use the docstring as a declaration of intent. So in the docstring, I say what is the function or the variable meant to do, like what is it meant to provide. And then if I look at the code and I'm like, ah, this doesn't work, I know that the doc string is what I wanted. It's never the code. So there is this idea that the code is a source of truth. For me, it's the opposite. It's like the doc. It's the specification. And then the code is… I was wrong. I was sloppy. I wasn't paying attention. I missed something or whatever. And the reason for that is the following. It's because with the code, you may have used the symbol wrongly, or you may be calling something that you don't mean to call, or there is another function. Or, for example, you use mapc instead of mapcar, so you don't get the return value you expect, that sort of thing. So something, basically you don't deal with sloppy problems. So you don't have confusion there. You know that, okay, the source of truth is the docstring. This is my intention.

Sacha: I should do that more often. Now that I've changed my yasnippet for inserting functions to automatically have the docstring, I feel a little guiltier when I delete the docstring, so I am compelled to instead fill it out. But if I specify it in more detail, as you do with it becoming the statement of intent, then I can be like, OK, let's try that. It's a good practice. And then I can write the test.

Prot: And the thing with docstrings is that, of course, you are

Sacha: Yeah? This is me.

Prot: motivated to just write the minimum necessary so that you don't get the warnings, right, from checkdoc. But if you write more, then you are rewarded yourself. It's something that helps you, future you, and of course other users, because you always have to consider yourself as basically a user. I don't remember why I wrote this six months ago, so of course having the docstring there, actually spell it out, helps me.

33:46: Learning and reminders: Sacha: I definitely have problems with working memory and long-term attention. Which actually touches on this other thing that I mentioned in my post, which is, in your experience coaching other people and also in your personal practice, what are you finding as good ways to keep reminding yourself, okay, these are the keyboard shortcuts I want to internalize, or this is the the workflow tweak that I wanted to try naturally. I was thinking, maybe I make an Org file or maybe I make a quick help thing or whatever. But it's always interesting to hear about other people's workflows.

Prot: What I find most useful is to not try to memorize too many things, but whenever you are in the flow of, oh, this is a process that I want to be doing, to actually implement it as a command or whatever, as a package or whatever, like basically don't try to memorize the steps and of course the key bindings. Try to build a function that does those for you. A command basically that does those for you. So for example, to be concrete, I mentioned earlier that for video purposes, I will enable line numbers. And I will also enable the line highlight. And I have another thing where I disable spacious padding. So the package I have. And all this, of course, I know the key binding. So it's F7 and F8 and F6 or whatever, right? But I'm like, I cannot remember all that. I will just write a function, and it will be prot-streaming-mode. And I enable prot-streaming-mode, and it does what I want it to do, and then I disable prot-streaming-mode, and I'm back to where I need to be.

35:31: Encapsulating workflows into functions: Sacha: Yeah, I have a prepare-for-screencast that does something similar, changes font size, etc, etc. Tt's so wonderful that in Emacs, you can

Prot: Exactly.

Sacha: just keep collapsing things into functions that do the thing that you wanted, and it has access to pretty much everything. I just need to remember to actually call the thing and remember what the thing was actually called. Aliases are very helpful, so it's orderless, but it's like…

Prot: Another thing that might help is long names. Because with long names, you have more chances to match it. For example, in this case, it could be called prot-streaming-mode, but you could also call it prot-streaming-and-video-demonstrations-mode. And of course it sounds ridiculous, but if you think about it, I might search for, I do M-x and I search stream. I find it. I search video. I find it, right. I search demo. I find it. So, if you care about something, you can name it that way, and then you find it more easily. Or, of course, with aliases, you do the same, right? prot-streaming-mode, alias, prot-video-mode, alias, you know how it is. But, yeah, either of those would work. Basically, benefit from the fact that you have completion, and I imagine you also have orderless.

Sacha: So definitely that. And then

Prot: So, yeah.

Sacha: for the free form notes thing, it just occurred to me.

37:05: Popping up notes: Sacha: So in addition to your posframe stuff in your config for quickly popping up an Emacs posframe for some commands, like, do you have some things? I suppose I could just use that directly for my notes and for the chat. Do you have any other of those "quickly pop up something so that you can do something with it and then make it disappear?"

Prot: No, I haven't built a lot on that. So I have some functions I do

Sacha: That's your main thing.

Prot: with that. Specifically, I have it for the timers. For me, that's very useful. And for org-capture, but I haven't elaborated on it. Of course, I could do that more. Another that I… By the way, it's not a poframe. Technically, what I have is just a new frame. But the idea is the same, right? It pops up and it disappears. And I can share the code for that. It's in the prot-window package, actually.

Sacha: I have it highlighted here in my…

Prot: So it's a small macro there.

Sacha: So this is the thing that I was telling you about earlier where it just extracts all the things that I've highlighted. It's very, very cool. It's in one of these, I'll grab it eventually. Which is good because I have to go over my config at some point.

38:21: Rediscovering things in my config: Sacha: There's so much in there that I've completely forgotten writing about. And so I'm like reading this now as I'm splitting it into different modules and saying, oh yeah, I automated that. I'm doing it manually again.

Prot: The other thing that might help is a prefix key. So I have done that with C-z. So it's a prefix key, and then either with which-key or with Embark, you know, the Embark… When Embark replaces C-h. I forget how it's called now. You can always see, OK, what do I have? Like, what are the groups? And then you can cluster things there. And it's very easy. Ever since defvar-keymap, ever since that became a thing, it's very easy to write prefix keymaps, because it has a keyword called prefix, and then with that prefix you define how the keymap should be called as a command.

Sacha: That's interesting. I should definitely look into that. Finds how it should be called. That's a command. So you can just add it to other key maps as needed. That sounds cool.

Prot: So consider this difference, like right now, you can take a defvar, which is a keymap, right? And you can bind it to a key, the keymap itself, without the quote, you can bind it to a key. So you will do define key in the global map, like whatever you want, and then bind it. What happens though with that is that you're binding the value of the keymap to the key, which means if you make changes to the keymap, your key doesn't know about them.

Sacha: I've been running into that. I get annoyed and I have to keep re-evaluating my definitions. So yeah, okay, that's what I do.

Prot: Whereas if you have the prefix, which is now a command, you have created an indirection. So now you define key to the symbol that you have specified. And that, of course, is that indirection, which now gets the up-to-date value of the keymap.

40:31: Catching up on Emacs developments: Sacha: So this is Emacs stuff that I have been missing out on, because for the past 10 years I've just been squeezing things into whatever moments I can have before somebody comes and says hello and says mom mom mom mom, and now that I have a little bit more focus time, I'm looking forward to finding out about all the cool stuff that has gone into Emacs and that I'm not currently taking advantage of. So things like, for example, I only scratch the surface of using Lispy, and I want to do other things as expressions because it's all magical. And if you have similar, like, oh yeah, this is a new thing in Emacs 30 or 31 that is super helpful and not everyone knows about it, I'd love to know about it. I mean, I know it's on Emacs News, but sometimes I'm like, whoosh, it goes past my radar and I don't have the time to dig in.

Prot: Yeah, right now I cannot think of something. But yeah, I will.

41:29: diffs: Prot: Oh, a very small thing that helps me a lot when I make any kind of edit. You know, there is this function diff buffer with file. So that's good. For me, what I always want is

Sacha: that sounds like a little tweak

Prot: diff-buffer with a current file. I don't want to diff a buffer with some random file. So what I have is a very small extension, a very small function, which is diff-buffer-buffer-file-name. So buffer-file-name is the variable for the current buffer's file. And then I do the buffer file name. And for me, that's very useful. Whenever I make an edit or I'm not sure what happened, I do that and I already see the diff. I use that a lot.

Sacha: that I would love to to pick up as well. There's all sorts of interesting workflow things that I am looking forward to discovering as I figure out the better way to watch videos and then also make videos, because one of the things I find is whenever you demonstrate something, sometimes, if you're really lucky, someone will say, oh yeah do you know about this thing that does the whole thing, which is great. One of my favorite reasons for sharing things is learning from other people. All right. You write this really long blog

Prot: Same. Like you put it out there and somebody will be like, hey, you could do it this way instead.

Sacha: post about this clever thing that you just figured out and then five minutes later, oh yeah, that's been built into Org since, you know, version 9.7.

Prot: Exactly, exactly.

43:08: Thinking about the community: Sacha: Which actually leads me to: what can we do? We've got about 20, 15 minutes left in this hour. Taking advantage of your very large context window for all things Emacs community, you know, those kinds of stuff that we are interested in, what are some of the things that we could do to make things even better? This is a very open question, of course, but yeah.

Prot: Even better, you mean Emacs in general or Org in particular? Because Org got a very nice feature lately, Org 9.8, which is the ability to preview images for any link type. So that's very useful. Before it was like the file type. Now it's any link type. And of course, if you ever want to do something with a custom link type, there you have it.

44:00: org-link-preview: Sacha: Which is good because I, in fact, have an override for a custom link type where I had done it before. So I just basically copied and pasted the image preview link so that I could have my SVGs either included in it as a whole or just preview. Anyway, so yes, I'm going to switch over to the new one. Link preview, update my code for SVGs.

Prot: Yeah, for example, now imagine this. Imagine you have a custom link type, which is called image or something, and you just give the image a name, nothing else. And internally, this link type knows to go in a specific directory and get the image from there, maybe even have copies of the image, so it can give you a copy that matches some parameter or whatever, like some user option maybe. You could have fancy things like this. I have been thinking about it, but I haven't written anything yet.

Sacha: I would probably like… Things like my audio waveforms could go in there very easily and things like that. I'm very curious about this idea of mixing more things into other places in Emacs. And one of the things that I've been meaning to dig into is how LECDraw does SVG interaction, because it uses mouse events to be able to drag things around and whatever. Because I think if we can get richer interactivity and more graphical elements, that could be really fun.

45:31: Prioritizing things to work on: Sacha: Anyway, but yes, so I've got basically three months of focus time before the kid goes on summer vacation and wants my attention at probably the majority of the day at an irregular interval. So it'll be a lot harder for me to schedule things then. I can set aside maybe 10 hours a week to work on Emacs-y things, including possibly working on infrastructure for the upcoming EmacsConf, or tweaking Emacs News or hosting meetups or whatever. Taking advantage of you as an external perspective, are there things that would be a good idea for me to particularly focus on? Things that you've been wishing you could say, Sacha, hey, just do this thing and it'll be awesome.

Prot: I think you already have a very good setup, actually. So I don't think there is much to be done in terms of adding things. Maybe the work here is to be removing things, and that's the more difficult part.

Sacha: No! Delegating things. Passing things to other people, maybe. Making it possible for other people to help.

46:52: Modelines: Sacha: Yeah, I don't use the mode-line as much. I ended up moving keycast to the header line because it's a little bit more visible in videos. Sometimes when closed captioning is on, it obscures the mode line. So I don't tend to look at the mode line for much, and I'm wondering what I'm missing out on. And I'll probably also want to add: am I streaming?

Prot: Yeah, not much. Not much is the answer, but maybe you could declutter it in that regard so that then it is useful. For me, where it really is useful is to know some things such as, of course, what is the buffer name? Is the view narrowed? That's, for me, really important. Maybe is it a read-only file? And am I running a keyboard macro?

Sacha: Is my microphone on?

Prot: Yes. Good, good. You see, there are all sorts of good ideas. And you can think of those as just one character, right? And you can have that one character with a face, which has, for example, a background. So is my microphone on? That's a green background. Am I streaming? That's a red background or whatever. And you just see the colors there and you know everything is all right.

Sacha: Although, actually, now that we're talking about it, I'm thinking maybe I should just revive websockets. So I made an obs-websocket.el thing before, and someone has… The benefits of making a package: someone has actually updated it to work with the new WebSocket protocols. I just have to get the whole thing set up again so I can communicate with OBS. I can use a different theme, most likely another Modus theme, when I'm streaming, so that it's a little bit more in my face: okay I'm looking at the correct colors, I am public.

Prot: That's the other thing. Yeah, that's good. That's good.

48:50: Themes would be nice to have per-frame: Prot: With themes, unfortunately, that's actually something I would like to have. We cannot have them per frame, which is strange because if you do set-face-attribute, you can specify a frame argument. But if you do something like custom-set-faces, you cannot.

Sacha: I'm sure that once you start messing around with Emacs internals, you might be able to figure out the way to do that.

Prot: Yeah, now that I say it, it shouldn't be too difficult. Yeah. Famous last words.

Sacha: Yeah, yeah, yeah. That's really fun. Okay, so that gives me stuff to work on.

50:11: Getting together: Prot: For me, yes. Even more frequently than once a month. Whatever works for you. For me, it works. That's the point. And also not in the context of coaching or whatever, but generally as a collaboration, I'm totally okay with that. Basically, more events for the community. I'm all for it.

Sacha: Yeah, because it is different. I very much had missed doing Emacs chats, and I'm so delighted that you've got Prot Asks. I'm looking forward to watching the one that you just released, because it's a community event, right? You get to know about interesting things about people. And there are a lot of things that come up through conversations that don't come up when you're just writing by yourself.

Prot: Yes, yes, yes. It's really that. It's really that. And for me, it's also another thing, which is it's more inviting. Like, it's like you are telling people, hey, show up like you can participate. Actually, we are friendly. Like, here we are. You see us. I think that kind of encouragement helps.

Sacha: So if you want to do, like, Emacs office hours on a regular basis, either something that you schedule in yours… Is it a YouTube thing where we can both schedule a live and then both have it, or not? I think they've got a collab thing now. I don't know.

Prot: I haven't explored it. So on the technical side, I really don't know. But in terms of intention, I'm all for it. So we can of course figure out the technicality.

Sacha: You have the bigger channel.

Prot: But I really don't know. We can do it twice a month, or even if you want, if you are really

Sacha: If you want to set it up, then Thursdays are probably good. Or if you want me to set it up, then I can do that. And then we can figure out the platform details and the non-YouTube way for people to join… probably IRC. We've got all this lovely infrastructure for EmacsConf, which I dust off every month for meetups. So that's certainly something we can slide right in there too. Okay, so if we do it once a month, that just gives me three sessions of practice, but if we do it like twice a month or more, I am also okay with that. I think we can squeeze that in and make that happen.

Prot: into it, once a week, a live stream once a week. And yeah, people can join, and we can always have a topic and talk about it and take it from there. We could also do it. Now, I don't know whatever makes more sense, but we could do it on my channel. And then, of course, with a prominent link to your channel, or we can do it one on your channel, one on my channel or always on your channel. Me, I don't mind at all. Like me, I'm in for the fun.

Sacha: We'll figure out the technical details and whatever off-stream. It could be interesting because then that gives people a friendly place to drop by and chat. And also because I know you're there and I'm there, it gets away from the talking to myself. When it's just me talking and then it's just like chat is silent, it just feels like I have this unfairly privileged position. So yeah, that's definitely something we're going to look into. We can structure that as one of these coaching thingies if I'm looking for excuses to use the Google Open Source Peer Bonus. I still haven't really made a justifiably good plan for it. So yes. Okay. Oh, this has been very helpful. I've got like all these tips. If you're okay with it, I am totally fine with posting this recording online. If you want, you can also post it. I think there's some kind of collab thing.

Prot: Me, I don't have a recording. So you can do whatever you want. So it's really up to you. Me, I don't mind. The reason I don't have recordings of my meetings is because I really have this policy of, you know, it's private. Your name is never known. Nobody has seen this. That's the idea. Of course, in your case, you're making it public. So, of course, that's fine.

Sacha: Yeah, my stance is always, well, I'm going to learn stuff, but A, I'm very forgetful, so I need to be able to search it and find it again. And B, other people can pick up stuff too. I might as well expand the learning and do the learning out loud. So all that is good. And then for next time, which will probably be in two weeks, or maybe earlier if I manage to get my act together,

54:44: Namespaces: Sacha: I'd like to see if I can get my stuff properly split up into different modules that have the different namespace. I really think I'm going to end up shifting to the sacha- namespace instead of all the my- stuff. I used to use the my- namespace prefix so that people could copy and paste things more easily into their code. But now I'm like, well, if I put it in sacha-, then I'm not polluting their namespace if they're loading the whole library.

Prot: Yes, yes, exactly. Exactly, exactly. That's a good thing.

Sacha: So that's on my to-do list.

Prot: And with naming things, of course, I also hinted that in the article I wrote in response to your blog post. It really helps to think about the names. Also, with what we said earlier about finding things like so don't try to be too terse, too economical with the names like make the most of it.

Sacha: I'm using nameless anyway to hide the prefixes. Got to get the hang of using the keyboard shortcuts to insert things.

55:46: Verbose function names: Sacha: Yeah, so I do like having very verbose function names and just practically full sentences in the thing. All that is very good. So that's my main thing. Aand then of course, getting into more ERT… I have this function that now that lets me try to jump to the test or the file that's related to this thing. So we'll see how it goes, especially as I move things into these different functions.

Prot: Okay, okay I'm not sure how you are doing that, but if I were to implement something like that myself, what I do with the ERT tests, it's always the prefix of the ERT file and then the name of the original function, double dash and then the name of the original function. So, for example, let's say, modus-themes-tests, right? So then it's modus-themes-tests–modus-themes-load-theme, for example.

56:45: Naming conventions for ERT tests: Sacha: Okay, so that's your naming convention.

Prot: That's a convention. That's a convention, yes.

Sacha: I should try that. I've just been basically naming things as function-name. And then I was, like, maybe I should be calling them function-name-test. Or in this case, you know, package.

Prot: Just to add something to this, because you also named this, so the nameless user. So there is built into Emacs this thing called shorthands.

57:14: shorthands: Sacha: Yeah, I read about that, but you did mention that some people have been going back and forth about whether it's worth using it or whether it confuses things more. I think just leaving the names as is and then just displaying it differently seems to be like an in-between step.

Prot: So that's what shorthand does. The name is, for example, modus-themes-test. And shorthand, effectively, is a buffer local variable which takes the small prefix and maps it to the larger prefix. So modus-themes-test can be mtt, for example.

Sacha: Okay. All right. So basically it's a more powerful nameless, more configurable, and it's built in. So I should check that out also.

Prot: Yeah, you can check it. It's not configurable, like it doesn't give you too many options. But the point is that for this simple case, at least for the tests, I find it useful because I don't want to have like a railroad of a function name, right? So I just want to be looking at something that I can understand. And basically, the prefix of the test is just there for it to have a prefix. And then I know what the function I am testing is.

58:46: "I don't write bugs.": Prot: I don't write bugs. No, no, no, of course, I'm kidding.

Sacha: That's going to go in the quotes. Okay, I don't write bugs. I write a lot of bugs. That's going to go to the blog post. It's going to be very large. So you never have to use bug-hunter because you just don't write bugs in the first place. Bravo. Good for you.

Prot: Why didn't people think about that? Now, of course, I'm kidding. So the way it works is that they are actually standalone packages. So there is a distinction, actually, in my configuration. So there are the modules, which is the configuration blocks, what would be done with. And then there are the libraries, which are actually packages, like I could just publish them right now. For example, for the mode line, there is prot-mode-line. That could be a package tomorrow, no problem. So if there is a bug there, I will go and deal with it the way I would deal with any package, like edebug, toggle-debug-on-error, whatever it is that I am doing. So there never is a scenario where the code is in all sorts of places, scattered across the file, and then, of course, it's very difficult to track it.

Sacha: But for your config, if it's in multiple files and you need to bisect it… Bisecting can get you to this load-file over here, this require over here is where things break down, but then you have to… okay, I want to load everything above that point and then bisect into the thing, which is slightly more annoying.

Prot: In practice, it's not difficult, because the way I

Sacha: I don't know. How does that work?

Prot: load my packages, so in the modules themselves. So I have this macro, which has a condition case in it. Of course, usePackage has the same, but with usePackage, you have to have everything as a package, whereas what I have here is even if it's not a package. So condition case, and basically if there is an error, it tells me where the error is, and then I can find it very easily. I have never had a scenario (of course I was joking, but actually I'm serious)… I've never had a scenario where I was confused as to what was happening. It was always very easy to find the error. If it's a bug… Yeah.

Sacha: Errors are fairly straightforward because it complains about it, but when it runs but it just produces the wrong behavior eventually, then that's the annoying part that I've been using bug hunter for.

Prot: The only scenario I think now that I had an issue like that was with the mode line, actually. Because with the mode line, if you give it like a wrong face or something, I don't remember, it will print like several messages for everything that changes on the mode line. So you will get like, well, invalid face, and there will be like, in square brackets, 100 times of this message. So That's the sort of thing that indeed is more tricky, but that was not because of my code. It was because of one small tweak that affects the mode line, and then it was about figuring out what the error is there, what's the bug there. But if you have the configuration split up in ways that are logical or thematic, if you want, whatever bug is always in one spot. It won't cut between files. So for example i have a module which is theme in the wider set but the theme also includes fonts. because fonts are, in Emacs terms, part of faces, themes deal with faces, that sort of thing. So whenever it's something related to appearance, I know that it's in the theme. It cannot be somewhere else because of how I have written it. Of course, depending on how you split things up, you will end up in a scenario where you have bugs that go across files. For example, a common one is where people will have, for example, evil mode, right? And then they will load everything, and then they will have a separate configuration module, which is for key bindings. And basically, that's a disaster, because whenever there is some problem, you don't know which key binding relates to which package, and you are always in a state that it's hard to predict. And basically, you have to do every key binding with eval after load, this package, this key binding kind of thing.

Sacha: Oh, that's going to be fun. I do have a bunch of key bindings in my file, so I'll just have to see how that all gets organized.

Prot: If you have them, organize them by package. Define them close to the context. Okay.

Sacha: That's actually mostly what I've been doing, mostly because I think of it, I think of the key binding when I'm adding the package to my config, so it's right there. I just realized I could probably just copy the top of my config file with requires or whatever to a setup file, which bug-hunter can then load. So I can still probably use

Prot: Okay, good.

Sacha: bug-hunter with that. Anyway, thank you so much.

Prot: Yeah, sure. I just wanted to ask the last thing. What is the kind of bug that you have encountered? What kind of bugs are we talking about here?

Sacha: Recently, in my shifting of everything to the new system, I also happened to realize that I had updated my Emacs and then stuff wasn't highlighting in the mini buffer. I eventually found out that it was because I needed to upgrade certain packages. But in the meantime, I was like, what do you mean? Okay, emacs -Q, sometimes it's working, sometimes it's not working. Okay, let's start narrowing it down. And that was fun. The other thing that I recently had to bisect was: I was exporting my really large config after having split things up into different modules. One of the lines was causing it to go into like a debugging thing, but it would not tell me what it actually debugged. You know, the backtrace would just not happen. So then I actually had to narrow to region and then export the specific sections of my file until I narrowed it down to, okay, my defvar custom link needs fixing. So I do this kind of bisection a lot. Ideally, whenever I can, I like to be able to just write an assertion so that Emacs can do the work of narrowing down when this happens but sometimes it's just, you know, you gotta pick your range and then execute the thing and see what happens. So I'm always looking for tools because I write a lot of bugs. I'm sure by the time I see you again, it may be either next week or next next week, I will have more bugs to share and more things to learn from. But this is very helpful and I am looking forward to updating you once I get all of the stuff checked off my to-do list.

Prot: Very good. Let me know how it goes.

Sacha: Yeah, yeah, awesome. Thank you so much.

Prot: And for the live streams, we see how it goes. Yeah. You will tell me. Yeah.

Sacha: And it's okay to post this recording if you want to?

Prot: Whatever you want. Whatever you want.

Sacha: Awesome, all right, see you around.

Prot: Take care, Sacha. Bye bye.