My name is Corwin Brust and I
will be talking about getting started
with Emacs today.
I have been an Emacs user for a long
time. First of all, thanks and a huge
welcome to the conference
from me and
and on behalf
and back to the other people that
have been helping to organize.
It's been amazing just to be involved
with that and just, kind of, see
backstage.
So I've used a lot of different editors
in my time. That's
about 25 years as a professional
software engineer.
And most of that time I've been using
Emacs. I'll talk a little bit in a minute
(if I can ever find my slides)
about how I got into Emacs
but I think if you've used Emacs and a
lot of other editors for a long time,
something that you notice right away is that
you get good with it in a way that stays
meaningful.
You learn new things. Those things
stick with you. You learn how to
make it do new tricks and then
keep doing those tricks.
I want to mention that this
conference--oops,
this talk isn't about
how to adjust your
configuration specifically. I don't have
a bunch of good code samples in here.
There are other great talks at the
conference, particularly Andrew's,
that I looked at, that looked
like they might be more aimed at that
"hey, I'm just getting started with Emacs,
what are some things to try to make
it more comfortable for me starting?" This
is about how to think about the problem
space.
Hopefully, a good warm up as we
start thinking about some of the
lightning talks a little later on.
I'm just gonna quickly make sure I
can see my IRC buffer in case I run into
time. I didn't get my stopwatch started
for this one.
So all right, let's dive in.
We assume that we want to install
packages
and maybe configure some features. This
is particularly from the perspective of
where we're working
with a bunch of people on a team and we
want to get something done.
Some of us probably already have mature
Emacs workflows.
Others are installing it for the first
time.
So the first question is, you know,
in that context: what's the value
proposition? Why should I mess with my
machine, my mature Emacs
configuration, and impose my
ideas over the way somebody else is
learning Emacs? Well,
it can be.. I'm off my slides here a
little bit.
It can be a little bit
tricky
to learn Emacs. One thing that
helps us a lot
is if people that we're working with
can tell us, kinda, keystroke for
keystroke at times, what to do and
explain what everything is doing.
Using the same packages can really
help us working together on a project.
Speaking from my personal
experience,
it took me decades to get to the point
where I was excited to program in Emacs
Lisp. I've programmed in a lot of programming
languages,
but Lisp wasn't on my list. I looked at
my config that I was copy-pasting around
from generation after generation of
.emacs file or
recrafting it from hand and from Internet
searches,
to get the things that I needed when
I would quickly go install Emacs at some
new job or contract,
and
be able to to quickly get through that
workflow that caused me to install the
program.
You know, just
little simple one-liners that that
got committed to memory over decades
eventually just led me to a sort of "hey what's going on
here." And I credit
Jeff Goff, my good friend who died
earlier in 2020,
for my lifelong love of Emacs.
Perhaps EriK and I will talk about that
a little bit more in another talk we
have
scheduled, but Jeff was a huge
influenceo on us
in a number of ways and a huge
contributor to the Raku programming
language
which is very cool.
So, understanding how
to make a good decision about splitting
up configuration in a way to share it
across
people with really different uses of
Emacs... That's actually a
complicated topic and I want to
sort of back off and stare at it for a
second.
I think Emacs is about people, so that
means it's about community.
And community means we're going to
invite disagreement.
In fact, that disagreement
isn't necessarily a road-block to our
project. In fact,
some of the work that a community
project can invite us to do
is to get closer to each other by
inviting those disagreements, by
learning from them--learning from
different people's
styles and from how they argue,
and thinking about why they have that
perspective and
what technical benefits that
perhaps radical point of view might
carry away. Some people are really
aggressive arguers, and others
are very passive and really
couch their ideas
in distancing terms, to say, "well
probably, this is a good idea" or
"please double check me."
Those don't always necessarily indicate
how certain a person is, because we're
different. We have different ways of
communicating
ideas like certainty or excitement.
[Music]
When we think about a bunch of really
diverse programmers approaching Emacs,
probably one of our our first really big
challenges is just
to pick what we're going to go
after. There are a lot of
existing kit
installs and things like this.
My argument is that you could actually
get pretty far
just trading files around. Maybe the
more valuable
conversation to have is making the
hard decisions about, well,
"should we have vertical completion,"
should that be the out of the box,
and the people that want
the traditional splayed out over a
single line completion
for example in the mode line, those
people are going to
add a line of config
to their own setup?
The way to get there? I mean, how do we
find out what works? We don't want to
slow down the people that
are super productive with Emacs by
asking them to completely break their
workflows and make it easier for new
folks.
At the same time, we do
want to make sure those new people are
excited by Emacs and not turned off by
having to learn
the entire jungle of Emacs
history in the form of its
unique technical stylings for
things like frames,
buffers, and other unique
Emacs viewpoints on important
interface concepts, especially.
The encouragement here is to keep
the initialization for a project team
together as a crucible.
Rather than necessarily following our
defaults of
finding the simplest configuration
that generally work and letting people
customize it,
what if we tried to look
for fairly specific configurations that
we'll expect essentially all of our
developers to be using,
at least when they submit bug reports.
In particular, with this,
I think that degree of
experimentation
can drive back into the Emacs
development process. In the development
mailing list...
I'm hoping I'll get a timing cue
here.
In the context of Emacs development as a
greater
entity, we see some of these struggles.
Should we change this default?
Sometimes we can have the
sense that defaults in Emacs will never
change. The conversation is too difficult.
I think one thing that can help us get
there is evidence
that says, "hey my 30- to 40-person project
is using this set of bindings and
here's what we learned about
brand new Emacs users trying to come in
and get work done with that."
(Amin: Yeah you still have
a couple more minutes)
Oh, beautiful. Okay, great. I will try to
get through my last few slides that i
cut
in my last walkthrough, but I think i'm
going quicker today thank you.
Thank you.
So let's just recap real quick:
in theory, Emacs works
out of the box. That means we're
free to experiment. We can
throw it all away and start over.
As an organizational principle...
I don't know what I was thinking on that
slide, excuse me.
Bringing it back around
to the free
and open source software community,
our goal
is to enable users
to unlock their computers, to do as much
with them as possible.
That's the context to take with project
initialization, but sometimes
it could make sense to put...
[Music]
to put some gloves on. I've thrown up on
the screen here just a couple of other
ideas, ways to maybe think outside of the
box.
As you're putting together project
nets,
my words of encouragement are to experiment
with it,
try different things, and think really
specifically about how
different the development users
might be from each other as you
define standards for configuring
the user environment of Emacs
specifically for developing
on a project. That's pretty much my talk.
If there's any time, I would take a
couple questions.
Thank you for your awesome talk,
Corwin.
I think we have one or two
minutes for a few questions.
Do you have the pad open or would you
like me to read the questions for you?
Oh, I managed to close the
pad
and I am trying to open it again. All
right, there it opened.
Bringing it onto a screen where I can
see it. Will you read me the
first question while I drag windows
around, please?
(Amin: Sure. It says, "do you use Emacs as a
community building tool?")
Do I use Emacs as a community building
tool, or how do I?
(Amin: It just says do you.) Yes, absolutely.
I think Emacs is an ambassador to
the GNU tool chain.
I think that in the fullness of time, we
will see an Emacs
that makes
and that makes iOS and Android and other
closed-source
tools dream. That's why they mock us
and call
Emacs an operating system. It's because
it could be, if we cared for it to be.
It's quite a threatening product
from the perspective of how many problem
spaces it can address, how many types of
users it can satisfy,
the things that we can do to make
it robust in those
environments. I mean, we're always
thinking about the weak points, but
is Emacs a community building tool? Heck
yeah.
(Amin: There's like one or two more
questions.
I think they're more long-form so it
might be better
if you took them off stream so you
could keep the schedule on time.)
i would love to take those questions
offline. I will respond to you in
writing if we don't get to it in a
breakout room.
Thanks so much for joining us. I
can't wait to see the rest of the
conference. See you there!
(Amin: Awesome. Thank you again so much, Corwin.)