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