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