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:21: Development workflow:
Sacha: Yeah, and that actually brings me back to this Emacs Lisp
development workflow thing. So I think one of the things
that I just need to do is I just need to set up the Makefiles and
the snippets and the shortcuts to say that if I'm
starting a new proto-package, the thing to run the tests
is there, and whatever it is that maybe even continuously
runs the test when I make a change, and lets me mock up
functions so that I can test some of the things that might be
more interactive or might require deleting files or
whatever. It's just changing my buffer configuration and
whatever.
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:39: Modelines:
Prot: There is a very small thing which maybe is useful,
maybe it isn't. I don't know how much you use the mode line,
how much you rely on that, but the newer version of Emacs makes it
possible to shrink the lighters for the minor modes.
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.
- 49:27: Livestreaming conversations with Prot:
Sacha: I brought up briefly the idea of possibly
setting up some kind of streaming things because I think,
for example, this conversation that we have…
I have so far managed to not share anything
that is too private, except for, of course,
the time when the kid is like, hello, mom,
I need your attention and I want to be on stream.
She likes to make cameos.
So we could share this,
and we could potentially think about
having these kinds of conversations
as something that other people could join in on,
because it causes more questions,
it's more interesting, and it also gets stuff out there
without me having to type the lessons learned.
So is that maybe something we can consider doing,
I don't know, once a month for the next three months?
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:27: Bisecting config in multiple files:
Sacha: I had a quick question about the config. So you
have, in addition to your modules, you also have…
Your Emacs's configuration is also split up
into multiple files.
How do you bisect these things when you're tracking down the bug?
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.
