Hello, my name is John Cummings, and I'm here today
to play a Fanfare for the Common Emacs User.
By "common", I mean the types of Emacs usage
and comfort that are simpler, more mundane,
and yes, even imperfect,
that some may identify with more than others,
or more at certain times.
It's hard to use Emacs and not be aware of
the impressive and interesting accomplishments
of its community. And here at emacsconf
we also get pumped up about those things,
amplified by the energy of the other attendees.
But this energy fades as we return focus
to our day-to-day work. And in these circumstances,
we may unfairly judge our own Emacs usage
against the community highlights.
So I want to identify and celebrate the ways
that we common Emacs users use it,
the reasons why it's a good fit for those ways,
and some ways we could take advantage of that.
What is Emacs to us common users? Well, we're consumers.
We use whatever was available - whatever our OS gave us,
or whatever we found when we searched the web.
We're not even necessarily aware
of what the latest version is, or what changes it has.
We may not ever think about upgrading.
We have what we have, and we use what we have.
But I think, with this simple act, many of us
achieve a very significant Emacs milestone:
we've committed to having it in our toolkit
and our skillset. We'll probably install it
on every system that we can, eventually.
We know it has a use for us today,
and that it will solve some problems
that we don't even know about yet.
It will not just be one tool; it will be many.
And we know that it will be more than just useful;
it will also be challenging, puzzling, and frustrating.
But we still keep it
as a permanent part of our toolkit,
and we should be proud of that.
And regardless of what exactly we've installed,
it was a good choice.
It will almost certainly do what we need it to do.
Old versions are not inert dead-ends;
they're still functional tools.
And that's a key aspect of Emacs - it's a tool
to get our work done. That sounds obvious,
but it's easy to get distracted by the great things
that it can accomplish, and think
that it requires the same accomplishments from us.
But it requires no advanced state of mind,
no level of expertise to start using it,
or use it correctly.
It just requires that we have it, and use it.
And with a little effort, we can get results early on,
and those results are not just preparations
for better things to come later;
they have value for us today,
and we're already using it right.
And when we do need to tweak whatever we installed,
we might again be consumers, finding some snippets
out on the web, pasting them in, and moving on.
We don't necessarily understand what we did,
but we got some value out of it. Over time,
we may participate more, take it day by day,
and one day we may find that our config
has become a disorganized pile.
Maybe it's mixed haphazardly
with some output from the "customize" feature,
and eventually we start to feel
like it's a shameful mess. It's hard to manage;
we may think of it as append-only or read-only.
We can't deny there are problems here,
but it happened for a good reason. It was quick,
easy, and effective for us
to enhance our experience this way, and then move on.
We were using Emacs as it was designed here.
It just wasn't sustainable indefinitely.
We may continue doing things this way
even though we realize it's not a good idea.
But I think there are some ways
to mitigate the downsides,
that let us embrace our tendencies,
and continue to benefit from them.
If we allow and encourage ourselves
to capture our thoughts and circumstances
along with the work that we do on our config,
and do so without judgment, or the responsibility
to "do it right", we give ourselves the context
to understand and manage it later.
This should be done however works for us,
whether it's rambling inline comments,
keeping a separate journal or notes,
or even a more advanced literate programming technique,
if we want to make an investment like that.
Or putting our config into source control,
even if it's nothing more than a simple,
daily record of changes along with our contextual notes,
will make things a lot easier for our future selves.
But regardless of how well, or sloppy, we manage it,
we should also realize that our messy config
is a personal artifact with inherent value,
even if it's amusement value, or sentimental value.
Emacs is not only a tool to get our work done,
it can also be a very personalized experience.
And if so, then our Emacs config
is our experience in written form.
You can see it as a log of your journey through Emacs,
and the mark that you made on it along the way,
mistakes and all.
We may see our config as a record of failure,
of things that we did wrong, the things that we repeated,
or never finished. But it's important to realize
that a record of failure is a record of persistence.
In that sense, it's kind of like our genome:
a set of unique, disorganized,
somewhat accidental properties, that, on the whole,
makes us fit to survive in our Emacs usage.
It's also interesting to think of it
as an archaeological record. Where we can sometimes
get some insight into our "ancient times".
Just being able to see what we were doing years ago
is interesting -- to see how things changed,
and hopefully grew over time. And sometimes
we find some buried treasures that we forgot were there.
And of course it's interesting to realize
that when we start Emacs, this pile of config
also executes in roughly the same order
that we created it in. Our journey through Emacs
happens again and again every time we start it up.
And it's ready for us to keep working on it.
And when it comes to packages,
we may not make extensive use of them, if any at all.
We probably have different reasons for this.
We may feel like we need to reach
some level of mastery before we start using them.
We may not have the mental room to think about packages,
or may not want to take on the administrative burden
required to keep track of which packages we have,
the dependencies and versions, and their compatibility.
Some of us may just be uncomfortable
letting new third-party code run in our environments.
It could also just be the case
that our needs haven't driven us to need a package yet.
We're already doing what we need,
and doing it efficiently enough.
And here we find more alignment
between Emacs the tool, and our common mindset:
They work well when they stay needs-driven.
We're not obligated to use
as much of Emacs' functionality as we can,
or every package that we're aware of
if we don't have a need to.
And in fact, that's a great way to stay overwhelmed.
But if we stay aware of our needs, and then find
that there is a package that might address them,
then we can deal with it. And a need to explore,
and a need to be curious, is a valid need.
And if we do need extra confidence for that exploration,
then the things we talked about before,
like keeping good notes of our experiences and needs,
or version controlling our config,
will help us keep that connection to our needs,
that gives us the freedom to experiment
in the wide world of packages.
And if we really do just need what's built in to Emacs,
the vanilla out-of-the-box experience,
then we can also be proud that we're making use
of all the work that went into that experience,
because a lot did.
And when we report any problems that we find,
we're also working to keep that experience
smooth for future users.
Of course, some of us may find this intimidating,
and if so, feel free to reach out to me,
and probably anyone in the community,
that can help you navigate that process.
So how do we use our Emacs installation?
We often use it very simply: we get simple results
in simple ways. Often we do things the same simple way
for a very long time, and this is of course great,
since we're getting done what we need to get done.
There's no result or method too simple for Emacs.
And we're not oblivious to the alternative.
Many of us are at least aware that there are ways
we could iterate on what we do,
or some polish that we could apply,
and we may even quite enjoy
reading about more advanced Emacs possibilities,
and thinking about how they could apply
to our own workflow, but at the end of the day,
we still keep our own usage the same, and basic.
And this is another fundamental aspect of using Emacs.
You can work simply and successfully,
but you'll always be conscious of the possibility
for far more complexity. And many of us
do try to iterate on our ways, and sometimes succeed,
but often we run into trouble and we stop or defer.
A lot of times we're intimidated by the scope of things -
we're not sure how to make measurable progress.
We may find that the first ways we learned
are so ingrained in us, that learning even a second way
is many times harder.
And sometimes we do make sudden progress
after years of sameness,
and wonder why we waited so long.
And these are universal pains
that everyone has to feel who wants to improve.
But this is again where we can benefit
from letting our needs drive us.
Sometimes they'll tell us that it's OK
keeping things the way they are, and sometimes
they'll tell us that it's good to keep pushing,
because there's a reason for it,
and we'll be glad that we did.
And what are the ways that we do learn,
and grow, and create within Emacs? One constant
is that we forget a lot. We learn something
and then remember that we already learned
and forgot it once before. Sometimes we just hope
to learn more than we forget.
And staying driven by our needs can also help here,
because it's easier to learn something
when we have a reason to, and an application for it.
In Emacs, it can be tempting to do this backwards,
and want to learn all there is about Emacs first,
and then apply it. But again that's a surefire way
to stay overwhelmed.
And when we code and build things, we tend to create many small, quick things,
but never really integrate them deeply
into our environment or workflow.
We leave things half-finished once we get bored,
or find ourselves in over our head.
And this is natural, because we're curious and creative,
and Emacs makes it relatively easy, and actually fun,
to experiment and get these quick results.
But it's less clear how to see them through,
and inherently less fun to do the follow-up gruntwork.
But if we embrace our ways here,
and structure our workflow to support them,
we might find ourselves more satisfied.
So let's give ourselves permission, and a logical place
to put all our fun little quick experiments,
without having to worry about integrating
or polishing them, unless we find a need to later.
Let's use source control wisely to give ourselves
a place to experiment, and a place for stability.
Let's stay needs-driven so that we know
what we really do need to follow up on,
and what's OK to drop. And let's remember
that there is someone who will always appreciate
any notes about our thought process we can take,
no matter how rough or rambling they are:
our future selves.
And so I hope that some people can identify with
at least some of what I've shared today.
And I hope that we realize that,
no matter how we see ourselves as Emacs users,
and no matter what we see other people building,
we're proud of the fact that we have built
an experience that fits us. Thank you to everyone.