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.

Background

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

enthusiasm.

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

avoided.

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

laymen.

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.

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

seen.

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.)

Conclusion

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.

Also, 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?

Appendix

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

References:

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.