Hello EmacsConf! Hello world!
Today I will talk to you about
how Emacs made me appreciate
software freedom.
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.
So let's remove this header
from the top of the presentation
and proceed with today's talk.
In that header, you can find a link
to my website, protesilaos.com .
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. Not at all.
All I cared about was playing football
(association football, also known as soccer)
and staying outdoors.
My formal education is in the humanities
(or else, the liberal arts).
I had a career in politics.
I lived in Brussels, Belgium
where I 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 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 package.
The themes are modus-operandi
and modus-vivendi,
but they are grouped together
in the package called modus-themes.
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, as it is known).
The themes are built into
Emacs version 28 or higher.
A section of my website
is dedicated to them
as well as to all my other
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.
So let's proceed to the body
of this presentation,
and the first section is titled:
"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 ELisp
and with only a rudimentary understanding
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",
as it is known,
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 that and edit it 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 directly.
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.
Let's move to the next section:
"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, their combined form,
leaves something to be desired.
Their lack of homogeneity
meant that I could not develop
portable skills between them.
There is no inter-operability.
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 ELisp
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,
for example, create and delete windows
in a process that involves text editing
and some elaborate
file management operations
with Emacs's directory editor program,
or file manager, 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 [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
to a playlist,
create playlists, et cetera.
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 Emacs Lisp 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
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.
Next section:
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,
also known as ELPA,
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, that of spoon-feeding,
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 become productive with Emacs
and unleash its full potential.
What newcomers need is commitment
and an open mind to study what they have.
Next section:
"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 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 principle.
So let's move on to the next section:
"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 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.
You need to know what you are searching for,
and you need to know
where you will implement that.
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.
Next section:
"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.
And with this, I want to come to
the final section of this presentation.
The title is:
"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 you to further empower yourself
as a computer user.
I understood that freedom of software
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 the 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, folks,
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 this awesome community.
So thank you very much for your attention
in watching today's presentation.
Special thanks to
the EmacsConf organizers and volunteers.
This is all from my side, folks.
Thank you very much. Goodbye.