GNU Emacs Manual 26.1


I have read the GNU Emacs manual. Before you turn away and switch to a
less propaganda-oriented topic, let me pledge that I’ll try to stick to only
speaking about the book itself, and its influence on me, rather than the
software it describes. This may sound a bit counter-intuitive, but I am
aiming at the audience slightly broader than purely operating systems
enthusiasts or even professional programmers. And as such, the book as a representation of a way of thinking would be more valuable than the actual
software itself.



Now it is a bit hard to remember why exactly I decided to. It’s like,
there was a long chain of coincidences which made me finally choose this
weird reading as my relaxation book. The story was the following: I wanted
to learn functional programming, as I deemed the university course
unsatisfactory. Even though O’Caml is a great language, and F# is also an
interesting idea. Therefore I chose the most well-known book on Functional
Programming, that is, Structure and Interpretation of Computer Programs.
However, having worked as a full-time scientific software developer, I
intended to utilise all tools I had already gotten used to adapt conveniently
to my needs. However, it turned out that Scheme (the programming language
used as an example language in the textbook) has a fairly disorganised
community, which is quite democratic in making decisions, and certainly
capable of running language development, but is not particularly fit for
providing user-friendly tools. As an anecdote, I can tell my readers than I
myself actually had to fix a bug in one of the available tools in order to
start learning. What could be a more deepening experience!


That is, the most user-friendly tool for standard-compliant up-to-date
Scheme development is GNU Emacs. For ages I tried to avoid learning either
Emacs or Vi, generally perceiving them as tools of more geekish
showing-offness than actually useful software. However, there was another
event, which coincided with my interest in Functional Programming: I decided
to finally polish my knowledge of POSIX Shell, which is still a very useful
tool for file-juggling, although it’s leadership position has been severely
undermined by the onslaught of Microsoft Powershell and it’s foray into the
UNIX world. And by default, UNIX command-line uses Emacs-like shortcuts. So
it turned out that I already had some familiarity with the basics.

The first attempt


At first I didn’t intend to actually read the manual. Frankly speaking,
this was the first actual software manual I have read from the first to the
last page. (To be completely precise, I had read the Python language
reference before, but Python is, strictly speaking, not a piece of software,
but rather a general description of a whole family of technical decisions.)
Of course, I had *referred* to software manuals numerous times, but I had
always considered them to be useful as a reference material only, not as a
reading material with a plot and a style of narration. However, this turned
out to not be the case in case of the Emacs Manual. Or, at least, partially,
as the second part of the book resembles traditional proprietary software
manuals slightly more than the first part, which resembles what you usually
find in books with authors’ names on the front page. Indeed, in proprietary
software it’s much more common to get the information by reading what I call
`handbooks’ rather than manuals.

So I started my first attempt by going through the ‘Emacs Tutorial’ and
trying to learn on the way, which proved to be sub-optimal at best. No, it
doesn’t work like this. Especially if trying to use it to learn Scheme.

Second attempt: Learning Emacs Lisp

So learning Scheme ended up trying to fix bugs in Emacs plugins which
would glue Schemes with Emacs. And to fix bugs in Emacs requires knowing
Emacs Lisp, and Emacs Lisp requires you to know Emacs. How come did this
happen? I only know of one another example: that is to know C++ well,
it’s a really-really good idea to know C. Any other examples? Leave
your comments.

At that point I was ready to give up, but suddenly a patch of mine
was accepted into an Emacs extension, which gave me bit of

Reading the actual book

So I have read the book from the first page to the last, while
recording all the places I didn’t understand or deemed ‘cool’ on the
last page and all typos and bugs I had found on the first page.

It was a nice reading. Stallman does have a fairly smooth writing
style, and the book is very well prepared for the one ready to follow
the logic of the narrative. It has self-references, of which only a
few are forward references, although I think some of them could be

The book carefully describes the quirks and the incompatibilities
with a ‘common logic’, of which there are many due to the very old age
of the software discussed. It doesn’t try to enforce thinking that
these quirks should be accepted as standard, but it does encourage
thinking in terms of these quirks. Perhaps you would also be doing so
if you had a project that old under your supervision.


What is the book teaching you? Well, first of all it teaches you
how to write good manuals. Strictly speaking, the Emacs manual is not
comprehensive, although it does keep formal lists of the notation at
the end of the book. (Everyone is recommended to do so. It greatly
simplifies building a ‘memory map’ for your manual.)


I found how useful this feature can be when studying the ‘Systems
Engineering’ introduction by Wymore. He does have a similar notation
reference at the end of the book, although it is a bit incomplete, and
I had to augment it myself.

The book also teaches you about the way of thinking of a very
mature, experienced programmers. And even if you don’t intend to work
as a software developer yourself, understanding how outstanding
thinkers think is an invaluable experience.

The book also tells you about some old software conventions which
you might consider obsolete, but which are, surprisingly, still alive
in the software among us, and would be useful to be known even by

The way this book structurises your thinking about text, and
especially computer text, is enlightening. I have never truly
understood which exactly part of text formatting is due to be
described in the text itself, and which one is better be left for
metadata. Emacs Manual tells you what people of the Golden Age
thought about this, and their suggestions are, unsurprisingly,
valuable. For example, I learned how to politely denote paragraphs,
sentences, apostrophes and quotation marks using purely textual
notation without any formatting. As another example, this text is
written with inserting a single space between words and two spaced
between sentences. As simple but elegant solution which allows you to
help your computers manipulate sentences rather than words.


Again, this way of writing text is not enforced. But if you
follow the guideline, it allows Emacs to help you make your work
faster. (So that you would have more time for your stuff, rather for
typing text.)

Text has a lot of meaning in the world of computers. Even though
computers cannot truly understand text, they still leverage a lion’s
share of its power. Maybe Emacs’s way to edit text will not bring you
rocket speed in writing (although you will be typing faster), it
teaches you how much the power of text can be used in exchanging data
between software. In some way, it teaches you a different way of
thinking. In Windows the main way of moving data from one entity to
another is drag-and-drop, which is essentially forwarding a link. In
Emacs, as was in the old Lisp Machine computers, the typical ways of
exchanging data is copying and pasting. Which is practically what we
are doing now most of the time. So in some sense, the spirit of old
computers still lives among us.08-RobotsSpeaking.jpg

Because Emacs is so extensive, and because it is used for
something as important for developers as editing the main cooperation
medium of programs, the book just cannot avoid actually being one of
the most comprehensive textbooks on computer literacy ever. It cannot
just introduce you the ways of efficient text editing, it also gives
many-many contexts for the usage of computers. In particular, it
gives an introduction into tens of facilities provided by modern
computers, which inexperienced people wouldn’t even attribute to
editing simple text. Such are the computer mail system interface, the
agenda planner, the table editor, and even a few bot interfaces. I
doubt that people would actually use those tools nowadays, since for
many of us the job is still largely consisting of working with people
rather than text. But understanding what’s inside almost every robot
you’re using every day is extremely useful.

What’s missing

Two words: visuality and exercises.

Emacs has done a tremendous job during the past ~5 years to become
friendlier to a newbie. The configuration system is much more visual,
and although it could be done in a simpler way, in is a great
improvement in the newbie’s user experience, and a great help to
seasoned programmers. The help systems is wired into the whole fabric
of the program, and is one of the most useful help systems I have ever


Still, the visual component of the data representation is still
lacking. The book almost ignores the window menu, although it clearly
should have been documented just as every other piece of the program.
Clearly, the visual (rather than textual) representation is secondary
in computing, but that’s not an excuse to not use it at least for
displaying information when this doesn’t harm the user.


The exercises are another problem. Yes, we all know that making
exercises is hard, even very hard. But the efficiency of literally
every book can be severely crippled by the lack of exercises, as it is
not enough to just explain the tools. It’s also vitally important to
teach best practices and to help the student experience the
usefulness of the tool by himself. (I am aware of the XaH Emacs
Tutorial but it’s not a part of the official manual.)


Editing computer text is a vital still in the modern world.
Remember, I’m not speaking about just ‘plain text’, I am speaking
about the interaction medium of robots all around you. Therefore, some
way of learning how to edit computer text efficiently is crucial for a
modern human.

It may not be Emacs. It may be any computer text editor over
there, as long as it exposes the basic mechanisms of computing.
Notepad++, Vi, Visual Studio, you name it. Find the one which works
out for you. OmegaT may be useful for people working with foreign
languages, Microsoft Excel’s VBA editor may be the most useful for
office workers, and some internal Mozilla text editor may be useful for
those who spend most of their time on the web (like most of us). But
some was is needed. Emacs Manual served this purpose for me, maybe it
can serve the same purpose for you.

10-mozilla-console.pngAlso, reading the manual is a nice opportunity to read the GNU
GPL, which, unlike the core of the manual IS a political, rather than
technical document, although maybe just as horizon-expanding, as
the technical part, even if you disagree with it.

Shall this book be read at school?

Well, some book on computer text editing must (imperative!) be
read at school. Why not Emacs Manual?


The next review will be about GNU Coding Standards. (This is not a legal statement.)



This document is written by Lockywolf at 2019-04-01 Mon 22:28:10.
This document is distributed under GNU FDL latest version
The illustrations were found on the web and no effort has been
invested into tracing their origins.

One thought on “GNU Emacs Manual 26.1

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s