
Learn Emacs Lisp in 15 minutes - tangue
http://bzg.fr/learn-emacs-lisp-in-15-minutes.html
======
tikhonj
Basic Emacs lisp is _well_ worth learning. It takes Emacs from being _an_
editor to being _your_ editor.

With something like Eclipse, even adding a little bit of functionality is an
undertaking. You have to create a project, write a bunch of boilerplate, load
it and so on. With Emacs, it's basically effortless: a line or two of elisp
can do wonders. Sometimes I add functionality by just executing elisp directly
(with M-:), without even bothering to put it in a file! It's that easy.

This has really changed how I work. Now I don't think twice about having some
throw-away elisp for just one project. Or even just one file! Modifying the
editor (in small ways) becomes an action almost as natural as copy and paste.
Now Emacs is like a jazz performance, with room for improvisation: never the
same editor twice.

Emacs is also the perfect development environment for Emacs lisp. (Who would
have guessed?) It's the most integrated system I've ever seen; there is an
intuitive and remarkably consistent link between the lisp code and the editor
itself. I usually know how some bit of elisp corresponds to an action and
vice-versa. And if I don't, the incredible interactive help system is, well,
helpful: I can easily look up what function a keybinding calls or what keys
are bound to a function. These days, I do it instinctively, without thinking.
Throw in Emacs's general lisp prowess (paredit is incredible), the ability to
randomly evaluate an expression and see the results immediately as well as the
ease of inspecting variables and you have a very remarkable environment.

15 minutes as the key to all this? There's no question! Since you're going to
be using your editor for _years_ , it's well worth 15 hours or 15 days or even
15 weeks. (And since it's Emacs, you'll end up using it for more than just
programming: LaTeX, org-mode, blogging, chatting, email...)

Go for it!

~~~
recuter
An excuse to dive into lisp like that just might pull me away from Vim
(Vimscript is terrible, sigh).

~~~
terhechte
Have a Look at Evil, really good vim bindings for emacs

~~~
krisajenkins
+1. Evil is great. I think it's made Emacs my favourite implementation of Vi
yet.

~~~
sillysaurus
Well, the problem is that these bindings don't usually implement the corner
case Vim functionality I've come to rely on over the years. Can it record
macros perfectly? Does :%s/foo/bar/ work? How about selecting, then
:s/foo/bar/gi? Does the period key reproduce all actions properly? How about
:%s/foo\\([0-9]+\\)/bar\1/ ? Do all of the basic actions do exactly the same
thing as they do in a vim editor? Does % take you to the nearest parens or
brackets, then cycle between the opening and closing one? If so, I'm sold.
These aren't just random desires -- all of these are necessary for anyone who
thinks in Vim.

A few years ago I tried some emacs vim simulator and it had glaring flaws in
multiple categories. Vimpulse or Viper or something, I think.

It seems like it's a catch 22 because anyone sufficiently skilled with emacs
to design a perfect vim simulator also has no reason to do so, since they're
emacs masters.

(I'm on a phone else I'd check out evil now.)

~~~
sunesimonsen
It actually works similar enough that I switch between Vim and Evil daily
without getting annoyed. I usually use Vim from the terminal. The follow
things you asked about are all working:

    
    
      Macros
      Repeat
      :'<,'>s/foo/bar/gi
      :%s/foo\(bar\)/bar\1/
    

It is very actively developed and quite stable. There are of cause Vim
features that are not implemented yet, but the core seams to be very well
covered.

~~~
mjn
Interesting, maybe I'll give it a try. Do you feel any kind of impedance
mismatch from using emacs w/o the native emacs bindings?

~~~
aerique
No, Emacs should be configured to your liking. The default Emacs keybindings
(especially the more complex ones for common things) suck.

That said, you're still using Vim keybindings within Emacs and for some
operations that Vim has no equivalent for you will need some Emacs knowledge.
Also, some thing that Vim does have an equivalent for are easier to do in
Emacs.

You cannot step into Emacs + evil-mode thinking you will never need to know
anything else. You would be well advised to learn some Emacs basics and then
help functionality.

For day-to-day operations like buffer editing you'll be able to use you Vim
muscle memory.

------
artagnon
If you don't know Emacs Lisp, there's no point of using Emacs. You'd probably
be more productive in Vim or [insert favorite proprietary editor here].

Emacs Lisp is probably the most featureless language you can think of; it
doesn't even do basic threading and the async stuff is a joke. All the major
programming language modes are implemented as ad-hoc Elisp regexp parsers
making bugs impossible to fix. Virtually _everything_ is implemented in Elisp,
because the C code is a gigantic unmaintainable mess. This means that all the
pretty high-level stuff like Magit is _shit_ slow. Good features take ages to
propagate to upstream, whose reasons are often more political than technical.

However, it is the only programmable editor in the world, and people continue
to churn out more and more Elisp. Recent developments like MELPA and Marmalade
have made packaging and distributing easier than ever, and users just need to
`M-x package-install` to get their favorite packages set up.

The reason Emacs has been so successful is very simple: there is one global
environment where all symbols are bound; any package can overshadow any
existing symbol (variable/function) from anywhere. There are no "core"
functions versus "library" functions; any package can modify very "core"
behavior (for instance, find-file) very easily [1]. Ofcourse, this has severe
downsides: you can eval bad code and screw up your Emacs environment pretty
badly (it might even refuse to quit); often the only way to recover is to
restart Emacs, flushing the environment.

I'd say: learn as much as you can about editors from this monster; enjoy
tinkering with it. Hopefully, a fresh community will come together to build
another programmable editor soon.

[1]: The exception is the few C builtins.

~~~
treerex
I always get a chuckle out of people complaining that Emacs is too slow. Maybe
I've just "gotten used to it", but when I first started using it I was sharing
a Sun 3 with ten or fifteen other people.

I'd also argue that modes in other editors are ad hoc regexp parsers in some
other form... regexps, in the hands of someone who knows what they're doing,
work well.

And yes, virtually everything is implemented in Emacs Lisp. That's the whole
point.

People have been trying to build "another programmable editor" for 30 decades.
It hasn't happened yet. Why do you think it will happen soon?

~~~
jasonm23
30 Decades!!! wow.

~~~
James_Duval
Emacs didn't work very well on the Bouchon loom
([http://en.wikipedia.org/wiki/Basile_Bouchon](http://en.wikipedia.org/wiki/Basile_Bouchon))
but dammit, they tried.

------
mickeyp
I would encourage would-be Elisp hackers to read the info manual "An
Introduction to Programming in Emacs Lisp" that is bundled with your Emacs
(`C-h i` then select "Emacs Lisp Intro" from the Table of Contents) as it
enables you to evaluate the example lisp forms in-line in addition to being a
really great and pedagogical introduction to elisp.

------
king_magic
Ha, this is perfectly timed. After years of being a vi/vim user (not for any
particular reason, it's just what I learned a few years back and just stuck
with), I decided to start running through the Emacs tutorial for the hell of
it yesterday.

I really miss Lisp from my college days, and being able to work it back into
my regular workflow just sounded like a fun idea.

I read through this tutorial and its really a great introduction, really well
written and very clear. Nice job!

~~~
hannibal5
vi is the god of editors.

emacs is the editor of gods.

~~~
s_baby
emacs is the editor of sore wrists.

~~~
hannibal5
Q: How do you recognize experienced Emacs user?

A: Foot pedals.

[http://bc.tech.coop/blog/041024.html](http://bc.tech.coop/blog/041024.html)

[http://www.cb1.com/~john/computing/emacs/handsfree/pedals.ht...](http://www.cb1.com/~john/computing/emacs/handsfree/pedals.html)

~~~
chrismonsanto
After a decade of Emacs, I never had wrist problems, but I did end up
developing pinky problems, due to remapping Ctrl to Caps Lock.

I tried foot pedals (and still have them under my desk). They were better than
nothing, but after I switched to the Kinesis Advantage keyboard I ended up not
using them anymore. Hitting Ctrl+Alt with your thumbs is more convenient than
hitting them with your feet, especially since I tend to fidget a lot. Another
advantage (no pun intended) is that the arrow keys are convenient to hit,
which lets you remap several standard Emacs keybindings. For example, I use
C-b to switch buffers.

Neither switching keyboards nor using foot pedals solved my hand pain,
however. I ended up having to take more drastic measures: I switched to the
carpalx QGMLWB keyboard layout[1]. One of the advantages of the carpalx
approach is the clear and powerful mathematical model which quantifies the
effectiveness of keyboard layouts. I was able to select a layout that
minimizes pinky strain--if I had switched to Dvorak or Colemak, I would have
_increased_ my pinky strain.

[1]:
[http://mkweb.bcgsc.ca/carpalx/?full_optimization](http://mkweb.bcgsc.ca/carpalx/?full_optimization)

~~~
s_baby
>A: Foot pedals.

That's hilarious.

I get that emacs has technical merit but the keybindings are horrendous. Even
if they don't cause hand pain they're long-winded and distracting.

~~~
treerex
> [B]ut the keybindings are horrendous. Even if they don't cause hand pain
> they're long-winded and distracting.

Ha, after 26 years using Emacs I find Vim's keybindings long-winded and
distracting. To each their own. However, unlike many people I don't dismiss vi
because of unfamiliarity, or use them as an excuse not to learn the editor. I
try to use it all the time, but I can never seem to train myself to do non-
trivial things with it.

I have the similar problem with other editors: I've seen people rave about
Sublime Text, yet none of its killer features (modulo multiple selections)
really strike me as worth switching. And any of its features I think I want I
could (conceivably) implement in Emacs, so...

~~~
simonb
With regards to multiple selections, have you seen:
[http://emacsrocks.com/e08.html](http://emacsrocks.com/e08.html)
[http://emacsrocks.com/e13.html](http://emacsrocks.com/e13.html)

~~~
sgrove
That looks great! Earmarked to check out on a rainy day. Thank you for
sharing.

------
lelf
_unless you get so angry that you throw it on the floor_

Hey, just M-x doctor

------
benhsu
If you don't like lisp-interaction-mode, you can also use ielm (M-x ielm) as
an elisp repl

------
eksith
That was actually quite helpful. I've had the toughest time "thinking in Lisp"
as I'm told I have to do to get my head around it (also because I work with
the C++/C#/PHP family and switching between them and Lisp doesn't help).

I really appreciate the simple instructions in that regard.

~~~
TomDavey
I'm not a professional programmer, but I spend all day in Emacs primarily
because of org-mode. Two years ago I read about org-mode here on HN and was
inspired to give Emacs a shot. Today Emacs is my main technical hobby.
Extending Emacs with Elisp is a pleasure and a joy. My various init files
total over 3,000 lines of code that I wrote my own little self.

That said, while I remain incredibly impressed with the integrated
documentation system, especially the Info manuals for their sheer literacy and
clarity, I discovered over time that it doesn't adequately teach you "the Lisp
way." Explanations of the basic concepts -- like a symbol for crying out loud
-- are scattered and not really complete, leading to frustration as I got
deeper into extending Emacs.

For me, the light bulb went off after I worked through Seibel's Practical
Common Lisp. I've also read chunks of PG's On Lisp. Together these two
outstanding books resulted in an epiphany regarding Lisp and the functional
approach in general.

The result is that, where before I couldn't figure out Emacs's own Elisp
sources (i.e., "Why is this function written this way, and not that way? Why
do I see this idiom so often, what's it doing?"), now I can. The payoff for
writing my own Elisp has been incalculable. Now I'm fired up to read SICP, and
Felleisen et al, hoping to learn more about functional programming.

~~~
agumonkey
Allow me to suggest Coursera. They have nice courses about FP. Somehow in
simple -> difficult order.

Systematic Program Design by Gregor Kicsalez (I believe influenced by HtDP).
Programming Languages by Dan Grossman. (50 50 HtDP SICP and Brown University
material)* Functional Programming using Scala by Martin Odersky (influenced by
SICP).

In case you can already do the SICP exercises without issues then you won't
need these, but otherwise, the deadlines and automatic grader were great ways
to keep a regular pace in learning.

*) this course focuses on semantics, and language design, the problems are not hard applied problem solving, that's why I put it in 2nd, but they can twist your mind quite a bit when dealing with different meta-levels.

~~~
TomDavey
I've never heard of these. Thanks much.

------
adambard
This will definitely be merged into learnxinyminutes.com when I'm back from
vacation :-)

~~~
pattisapu
Ditto -- thank you -- this site is awesome. :)

------
chiachun
I felt that the "Teach Yourself Programming in Ten Years" was also very
helpful.

------
dschiptsov
Emacs is a miracle, no doubts. It is self-descriptive and self-contained
system, like Smalltalk (you could lookup any function, variable or even key-
binding, without a fancy browser, but in a way that is good enough). There is
nothing much to say, actually. Emacs is just a wonderful thing.

~~~
patrickmay
Indeed. The most value I got from from learning to customize Emacs wasn't the
functionality I implemented but seeing how powerful a domain specific language
can be. The ways that Emacs Lisp supports working with text, whether data or
code or documents, showed me what I should be aspiring to when I create a DSL.

~~~
dschiptsov
Imagine, then, what a wonderful thing Open Genera was.)

~~~
DennisP
Apparently an older version was opensourced at some point. I don't see why the
people who love it don't port it to x86.

------
marincounty
1\. Every book on computers, or anything technical should read this guys blog
before they get fire up the word processor.

2\. My biggest gripe about 99.9% of COmputer programming books are: They are
long. They are poorly written. They read like a telephone books.

3\. I once heard one famous programmer state, I won't read a programming book
with more than 500 pages. I think he was off by 400 pages?

4\. I truly believe if you take 80% of words out of most books; it would make
learning a subject easier.

~~~
Ziomislaw
writers get paid per word, still wondering why 80% of book has no substance?

~~~
gcr
Peter Van der Linden included a recipe for Oobleck¹ on the last few pages of
"Expert C Programming: Deep C Secrets". It's right after the Phony C++ Job
Interview Answer Key and right before the paragraph-long rant about Dr Seuss's
influence on the software engineering profession.

[1] [http://en.wikipedia.org/wiki/Non-
newtonian_fluid#Oobleck](http://en.wikipedia.org/wiki/Non-
newtonian_fluid#Oobleck)

