EmacsConf 2021: How Emacs made me appreciate software freedom
Raw link: https://www.youtube.com/watch?v=OE3mfOp5ZDI
This is a republication of my presentation at EmacsConf 2021. I am posting it on my own channel for archiving purposes. Original: https://emacsconf.org/2021/talks/freedom/.
The video was recorded on November 5, 2021.
What follows is the text of the presentation in Org notation. Note that I had mistakenly said āconsubstantiveā instead of āconsubstantialā but only realised it after I concluded the recordingā¦ This is rectified in the text:
#+TITLE: EmacsConf 2021: How Emacs made me appreciate software freedom
#+AUTHOR: Protesilaos Stavrou (https://protesilaos.com)
#+DATE: 2021-11-27
* About me and this talk
Hello EmacsConf! My name is Protesilaos, also known as "Prot". I am
joining you from the mountains of Cyprus. Cyprus is an island in the
Eastern Mediterranean Sea.
My presentation focuses on the intersection between software freedom and
what we find in the Emacs milieu. Here "the Emacs milieu" encompasses
two magnitudes: (i) the program we use and (ii) the diverse, global
community of people that has grown organically around it. I will talk
to you about how Emacs made me appreciate software freedom and helped me
exercise it to its full potential. Personal anecdotes are not the main
focus of this talk. Rather, they serve the ancillary role of making
certain insights more relatable.
The presentation is theoretical in nature and targeted at a general
audience. No knowledge of programming is required. It is assumed,
however, that you are familiar with some basic concepts, such as the
fact that Emacs is extended with the Emacs Lisp programming language, or
that Emacs is a GNU project that champions end-user software freedom.
Let's start with a few words about me before elaborating further:
+ I was born in Greece in 1988 and was raised there. As a kid I was not
into tech-related activities. All I cared about was playing football
(soccer) and staying outdoors. My formal education is in the
humanities (liberal arts). I had a career in politics. I lived in
Brussels, Belgium and worked at the European Parliament, among others.
+ After some intense soul-searching I realised I did not want to be a
political operator any more and made radical changes in my life. I
have since come to terms with the fact that I am a philosopher.
+ I am not a programmer. Neither by trade nor formal education. I code
for leisure. I was not tech-savvy until my mid-20s. I have been
using GNU/Linux distributions since the summer of 2016. While I
switched to Emacs full-time in the summer of 2019. Before that switch
I was running a bespoke environment that involved several standalone
programs like Vim, Tmux, and a tiling window manager.
+ I am the creator and maintainer of the =modus-themes= (=modus-operandi=,
=modus-vivendi=). These are designed to conform with the highest
accessibility standard for legibility and optionally support the needs
of users with red-green colour deficiency (deuteranopia). The themes
are built into Emacs version 28 or higher. A section of my website is
dedicated to my Emacs-related contributions.
For the remainder of this 40-minute talk, I will explain how Emacs made
me appreciate software freedom, how it empowers me in my day-to-day
computing, and the lessons I have drawn from that liberating experience.
* The inherent Emacs qualities for an autodidact
Emacs has this reputation of being extremely hard to learn and difficult
to get started with. So how does someone like me, who was not even
tech-literate a few years ago, go on to use Emacs effectively? How do
you start from zero, with no knowledge of Lisp and with only a
rudimentary grasp of programming, to eventually maintain packages for
Emacs and even contribute directly to emacs.git and other sources?
The answer to these and related questions lies in the very description
of Emacs as a "self-documenting" piece of software. It means that Emacs
has a robust Help system which informs you about the state of a given
construct. Such as what the original and current values of a variable
are. Or whether some function is being "advised", else dynamically
adjusted, by another function and what that advice amounts to.
The self-documenting nature of Emacs is combined with the fact that it
consists of free software. Not only do we get information about what
Emacs knows, but have the underlying code readily available to us. For
example, every Help buffer provides a link to the source of the item it
references. We can study and edit that as we wish.
Self-documentation and free software are blended together with a third
quality of Emacs: its implementation as a Lisp machine or else its
ability to evaluate Lisp code and make use of it directly. The ubiquity
and uniformity of the Lisp interpreter together with the immediacy of
its results help one learn how to use Emacs and how to write Emacs Lisp
expressions. For someone who is self-taught like me and who often
learns through a process of trial and error, this is of great value.
Learning how to use Emacs and how to write in ELisp is the basic
skillset you need to also start extending Emacs for your own use, or
even for publishing packages and making contributions to emacs.git.
That is because the skills you acquire by tinkering with your =init.el= as
a beginner will always stay with you throughout your time as an Emacs
user. That is empowering in itself. It rewards your investment in time
and effort. The more you learn, the more capable you become to enact
change, to configure things to your liking and develop the exact
workflow that you want without making any compromises.
Compare that to, say, my tiling window manager. I can configure it with
a shell script. So I learn POSIX shell or, let's say, Bash. But my
knowledge of the shell does not extend to modifying the behaviour of the
window manager as such, because that is not implemented as a shell
script but in another language. So for an autodidact like me, it is
more difficult to learn yet another paradigm before I can achieve what I
want. How do you make that extra step without self-documentation and
the immediacy as well as transparency that you get from the Emacs Lisp
interpreter? It is more demanding. Which makes Emacs comparatively
easier when we account for the longer-term effort involved.
* The interconnectedness of the Emacs space
As I already mentioned, Emacs rewards you for the investment in time and
effort you put into it. In my experience, this makes it easier to
master than a combination of otherwise disparate tools, each with its
own paradigm of interaction and particularities of implementation.
Before switching to Emacs, I was using a combination of standalone
programs as part of a bespoke computing environment that I had pieced
together. The program called "Mutt" would handle my emails, Newsboat
dealt with my RSS feeds, the Music Player Daemon took care of my music
collection, while I was doing work inside of a terminal emulator which
was running a multiplexer (tmux) and Vim for on-the-fly text editing.
Each of these, and others related to them, are fine in their own right.
But their gestalt leaves something to be desired. Their lack of
homogeneity meant that I could not develop portable skills between them.
What holds true in Vim does not apply to the multiplexer. The prevalent
methods in the email client cannot be used in the RSS reader, and so on.
Whereas everything that is implemented in Emacs Lisp partakes in the
same environment automatically. If, say, you know how to use keyboard
macros to edit code, you already know how to use the exact same skill
to, say, create and delete windows in a process that involves text
editing and some elaborate file management operations with Dired. If
you have a command that scrolls down half a screen, it immediately works
in all your buffers regardless of whether their major mode is about
reading emails, editing text, enqueuing songs to a playlist, and so on.
Emacs provides a level of integration that I consider peerless.
Everything the user deals with is implemented in ELisp. And all the
user edits is ultimately done with ELisp. As such, the environment
itself provides the conditions for drawing linkages between different,
yet +consubstantive+ consubstantial, modes of interaction. For example, I
use =bongo.el= to play back songs from my music collection. My =~/Music=
directory is configured to have a special minor mode, so when I access
it with =dired= it has commands that allow me to enqueue albums/songs,
create playlists, etc. Also, I have an ~org-capture~ template which lets
me store the details of the currently playing track and tag it
accordingly. Continuing with the example of Bongo, I make it interface
with my RSS reader, =elfeed.el=, by having the latter add podcast and
video links to the former's playback queue. All this is done by simply
re-using the same ELisp skills I learnt while configuring and extending
Emacs.
The interconnectedness of the Emacs space empowers the end-user. It
makes such emergent workflows possible. And the best part is that there
are no dirty hacks involved: it is an innate feature of the system. You
are leveraging the freedom that Emacs gives you in a way that confers
agency on you. You assume the initiative. It gives you confidence to
continue honing your skills in anticipation of further optimising---and
controlling in full---your own integrated computing environment.
* The documentation culture of the Emacs community
If what I have mentioned thus far was all there was to the Emacs
experience, there would still be something to be desired. Because while
self-documentation is great, it is meant to draw from---and be a
complement to---some hand-written material. Both new and existing users
must be able to read what something is supposed to do, what its main
points of entry are, how it relates to other parts, and so on. This is
about the human aspect of Emacs, the strong documentation culture of its
community, rather than an irreducible feature of the program we use.
As a matter of packaging etiquette, every non-trivial form in an Elisp
library must have a documentation string. What a variable or function
does needs to be spelt out in clear terms. Furthermore, the best and
most well maintained packages, whether those are built into Emacs or
distributed via an Emacs Lisp Package Archive, come with their own Info
manual. Unlike a generic README, those manuals are more like fully
fledged books, with a table of contents, cross-references, and indices
for concepts, functions, variables, key bindings... In short, there is
a tradition around programming with Emacs Lisp which values informative,
high quality guidelines intended for end-users.
Apart from what each individual package does, Emacs itself ships with a
helpful tutorial for newcomers, a comprehensive manual, a book targeted
at non-programmers titled "An Introduction to Programming in Emacs
Lisp", as well as a reference manual for Emacs Lisp itself. All this
material, all that wealth of knowledge, is readily available to the
end-user through the built-in Info reader. The details on how to access
the Info reader are already explained in the initial learn-by-doing
tutorial. For people like me who are self-taught, the documentation
culture of the community ensures that we are not left behind. It gives
us the chance to learn from the experts and to become better ourselves.
Writing concise and clear documentation is also beneficial for those who
do it: it helps them clarify their ideas and improve their communication
skills. These contribute to fostering a more humane social element. In
my experience, the Emacs community has a propensity against becoming
elitist. It helps integrate new members by not hiding anything from
them, on top of Emacs' inherent emancipatory qualities as described
before (self-documentation, Elisp interpreter, free software). At the
same time, the community strives for excellence so it expects newcomers
to do their part in reading what is generously offered to them. There
is a difference between sharing knowledge and spoon-feeding it to users.
The latter method keeps users dependent on it and is thus detrimental to
them in the long run. The Emacs community disseminates what it knows
and wants newcomers to assume agency and be responsible for doing their
part in learning how things work. The community's documentation culture
and uncompromising standards ensure that even once-unskilled users like
me can be productive with Emacs and unleash its full potential. What
newcomers need is commitment and an open mind to study what they have.
* The Promethean Ideal of freeing know-how and expertise
The documentation culture of the Emacs community springs from a
consideration of practicality. When you explain what your program does,
it is more likely that others will show interest in it and incorporate
it in their workflow. Whereas freed source code that is distributed
without any accompanying documentation will most likely only attract a
handful of enthusiastic hackers. Still good, but could be better.
Apart from its practical use though, writing documentation for the
end-user shows a spirit of altruism, an ethos of caring for others and
wanting to empower them in their endeavours. It essentially is the same
as helping someone; helping them escape from the ignorance that
contributes to their sense of powerlessness. I experienced this myself:
by reading the docs, I was able to go from an unskilled rookie to a
competent Emacs user. Part of that competence consists in maintaining
Elisp packages and contributing code directly to emacs.git. Writing
documentation is about disseminating knowledge and expertise, not
keeping it as an exclusive right of some elite.
Allow me then to liken this to the ancient Greek myth of Prometheas
(Prometheus). Prometheas was a titan, or else a deity, who decided to
teach the know-how of handling fire to humanity. The art of fire is an
allegory about know-how in general, not specifically pyrotechnics. So
Prometheas liberated that key knowledge by taking it away from the
exclusivity of the gods and bringing it into the domain of humankind as
a libre resource. This act of altruism propelled humanity to new
heights. Every field of expertise is about handling "fire", in the
figurative sense of implementing essential know-how.
Why would Prometheas, an exalted being, ever bother with the fallible
and frail humanity? Why did a god want to empower humans instead of,
say, making them dependent on the know-how of "fire"? If we look at the
world around us, we witness how its overlords are unscrupulously trying
to enclose the commons and take advantage of expertise in order to
exploit us. Why would Prometheas not do the same thing and enslave us
for the rest of eternity? The answer is that unlike this world's
aspiring tyrants, Prometheas represents a higher conscience, one that is
not corrupted by egocentrism and the greed of short-term profiteering.
This higher conscience makes sense of the bigger picture and can foresee
that the distribution of know-how empowers those who access it freely to
reach their potential. It is no coincidence that the ancient sages used
the name "Prometheas", meaning the "prescient one", the "foreseer".
This is a lesson on the outlook we ought to maintain, where we aspire to
our highest. We want to be the best version of ourselves, by being more
like Prometheas. We want our actions to be guided by this Promethean
Ideal of liberating know-how, of making expertise readily available, and
of providing others with the chance to prosper. When we all do so, we
are collectively better-off. Free software is a microcosm of that.
* The 'killer apps' of Emacs
Let's be a bit more practical now. Many new users are attracted to
Emacs because it has one or a few immensely useful applications they
would like to use. This typically covers Org and/or one of its numerous
accoutrements. Though there are other excellent packages like Magit.
The fact that Emacs has such killer apps is good. It shows that its
extensibility is not some theoretical upside of the Lisp interpreter.
It has tangible utility to a wide user base, including those who do not
write Elisp themselves. Furthermore, those killer apps are good as they
help bring newcomers and potential future contributors to the fold,
while they provide real value to the existing members of the community.
The more people we have and the happier they are with Emacs, the higher
the chances that we receive some new ideas or code from them.
The notion of a killer app does, however, come with a latent downside
when targeted at outsiders to the Emacs milieu. And that is because
packages like Org and Magit do not have a standalone presence. They are
always used in Emacs or, rather, together with the rest of Emacs. Which
means that the user has to know what to expect from Emacs.
You may be aware of the type of user who proclaims that they want to
boost their productivity but who also expects immediate results. When
you bring the "killer app" rhetoric to such a crowd, you run the risk of
misleading them into a false sense of self-confidence and concomitant
expectations of success. Such users may be tempted to try Org, Magit,
and others but are most likely going to endure a frustrating experience
overall. The reason is that they are oblivious to what Emacs is and
what is required to get started with it on a sustainable basis.
Org, Magit, and friends are fantastic tools in their own right. But
they still are part of Emacs. To use them effectively you have to
develop at least a modicum of understanding on what Emacs does. You
must be patient and approach this endeavour with an open mind. Go
through the tutorial, familiarise yourself with the Help system, make a
habit out of reading Info manuals, and take things slowly. No killer
app can ever be a substitute for commitment to a cause; no vaunted life
hack will ever provide a direct conduit to some fountain of wisdom.
With regard to software freedom and user empowerment, what I have learnt
is that the impulse for the killer app ought to emanate from a position
of knowledge. First we need to temper our expectations and prefer
propitious growth in learning over instant gratification. With Emacs,
we have a strong foundation for our computing freedom: it consists of
the inherent qualities of the program together with the documentation
culture and creativity of the community. Once we learn how to benefit
from those, we have everything we need to become proficient in all the
modes of interaction that are available to us. Think of it as choosing
Emacs and Org, Emacs and Magit, Emacs and Org and Magit, et cetera.
* You can't be an Emacs tourist
What I just talked about implies that you cannot simply switch to Emacs
over the weekend or on a whimsy. You can't use it opportunistically to
run a quick demo with which to impress your peers and win some inane
"nerd cred". Forget about such frivolous superficialities. Emacs is a
sophisticated tool intended for some serious work. It has been around
for several decades and it incorporates the knowledge of a diverse group
of contributors. Even if you want to use Emacs just for Org mode or
whatever killer app, you still have to try to learn things in earnest.
You still need to read the relevant Info manual, understand how to make
changes to the plethora of user options on offer, and generally don't
feel lost while working with Emacs. This is more so if you use Emacs to
its full potential as an integrated computing environment; as your
general purpose interface to the computer, where you handle uniformly
coding and writing prose, your email correspondence, your RSS feeds,
your music collection, your agenda and to-do lists, and so on.
The difficulty of Emacs is much higher for those who approach it without
understanding what they are getting themselves into. Or for those who
are naive enough to believe that they can cheat their way out of
learning the fundamentals. The gist is that you cannot be an Emacs
tourist. You can't go into Emacsland thinking that you will spend a
couple of memorable days there and head back home to regale others with
stories about your adventures. It does not work that way. You commit
to Emacs for the long-term, for the freedom it offers you. Freedom in
the moral sense but also in the very practical ways in which you can
mould and extend your personal workflows with precision.
Now you may wonder why do I mention those things? Shouldn't we make
Emacs easier for everyone? Yes, we should make everything as simple as
possible. Though that still does not refashion Emacs into something
entirely different. We continue to have a potent tool at our disposal
that we must treat with the requisite respect. Take, for instance, the
various frameworks that set up Emacs in an opinionated way so that
newcomers get everything set up for them out-of-the-box. There is
nothing wrong with those frameworks. In fact, a large part of the
community uses them to great effect. However, the point stands: even
after every package has been set up for you, you still have to put in
the work in making use of your newfound computing freedom.
But, you may insist, is that not some sort of gate-keeping? Are you not
being an elitist by telling people how they must invest time and effort
in making the best out of their Emacs experience? No, I think this is
not elitism. There are no secrets here, no artificial barriers to
entry, no impediments to making progress, no tricks and gimmicks. It
just is a statement of fact. Freedom entails responsibility. It
requires people to take the initiative and assert control over the
factors that are within their reach. Freedom ultimately means that we
no longer remain dependent on being spoon-fed. We assume agency.
* Emacs as a champion of software freedom
To my mind, Emacs is the embodiment of the GNU project's ethos.
Everything you expect from a program that is underpinned by the values
of software freedom is found in Emacs. What you get is not merely an
ethical tool, important though that is, but also a gift that will keep
on giving; a gift for your further empowerment as a computer user.
I understood that software freedom is not about liberating the code
itself. It is about sharing libre code in order to emancipate the user.
The best way to achieve that is by emulating Prometheas: don't just give
people the so-called "fire"; offer them the underlying know-how.
Emacs taught me the virtues of software freedom in a way that nothing
else in the GNU/Linux space ever did. Here's an example from a few
years ago. I needed a Markdown editor. I wanted it to centre the body
of the text on display. It should have configurable font families and
point sizes. Spell checking for Greek and English should be included.
The colours had to be editable as well, so I could adjust them to a
level of legibility I was comfortable with. While there were plenty of
libre programs, I did not find one I could control and inspect to the
extent I can with Emacs. Which made me feel that I had stagnated: there
was an indelible line dividing users from developers.
Whereas Emacs invites you to blur the distinction between user and
developer. It furnishes the means to become proficient in it. While
the community complements those with its documentation culture and
overall creativity. You start off as a complete ignoramus but soon pick
up skills that remain useful for as long as you work with Emacs. And if
you really want to take it a step further, you know where to look for
inspiration and guidance. Before you realise it, you start writing code
in Elisp and can one day share it with others.
What I have learnt over the past 2.5 years as an Emacs user is that if
you go from scratch and are meticulous in your approach, you will need a
few days or weeks before everything starts to make sense. After that
initial awkward phase during which you familiarise yourself with the
basics, everything else will become easier to learn. It is a matter of
gaining more experience, one step at a time. As with every field of
expertise, Emacs expects you to work for it and to earn it. For me that
is worth it. In terms of being malleable in a consistent way and
transparent in what it does, Emacs is in a league of its own.
In conclusion, Emacs allowed me to assert control over a great portion
of my quotidian computing. It helped me grow out of the state of
ignorance I was in; a state that rendered me powerless to use the
computer exactly how I wanted. For that I am grateful. I now consider
it my duty to contribute back to this wonderful project and community.
Thanks for your attention! Special thanks to the EmacsConf volunteers!