
Tips on Emacs Lisp programming - nic-ferrier
http://nic.ferrier.me.uk/blog/2012_07/tips-and-tricks-for-emacslisp
======
jrockway
It _is_ weird to use CLOS with Emacs. First off, you don't get a real CLOS
implementation, you only get superficially similar syntax. Many critical
features are missing. Secondly, your users lose the ability to customize your
package in ways you didn't design for. (In other disciplines of software
engineering, you're writing software that must run unattended without error
for years. In Emacs, you're writing software for a programmer sitting in front
of your program. The engineering compromises to make, therefore, are
significantly different.)

To do something like OO in Emacs, define variables that are buffer-local, and
then use the buffer as the object.

~~~
nic-ferrier
Obviously I agree disagree, which is why I wrote it.

"Many critical features" - I disagree, it's good enough OOP, as capable as
Javascript's for example.

Maybe you shouldn't consider it for a user mode or some such (though I don't
see why, there are enough modes that _do_ use it) but I made clear in my
article that I was asking people to consider EmacsLisp as a real language in
which you could write programs that are not just Emacs programs, scripts for
example, which I specifically alluded to.

Web programming is also possible of course, with Elnode - <http://elnode.org/>

~~~
jrockway
Just because you can hammer a square peg into a round hole doesn't mean you
should. The primary use case for Emacs Lisp is for extending Emacs. At that
task, it does a pretty good job. As a general-purpose programming language
it's not horrible, but it's not great either. You'll be much more productive
if you use one of the many excellent general-purpose programming languages for
general-purpose programming. CL and Scheme, for example, are fine.

Emacs Lisp's flaws are forgivable when writing Emacs extensions because it
integrates so well with Emacs. But without the Emacs integration, it's not
that great.

~~~
nic-ferrier
Of course, I totally disagree with this, which is what the premise of the
article was. EmacsLisp is now a general purpose programming language that I
think competes well with Python or Ruby.

But of course, it's not suited to every application.

------
pjscott
I'm still tickled by the fact that object oriented programming in elisp is
just part of a standard library you can import.

~~~
tikhonj
This is why I think some Lisp (probably Scheme rather than elisp :P) is a
great introductory language: very little is magical or built into the language
itself. So you learn about things like OOP as patterns rather than as the one
and only way to do stuff ( _cough_ Java _cough_ ).

~~~
pjscott
That's the approach that SICP takes, and it works really well. Among other
things, they show you how to make a basic object system.

<http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html>

~~~
nic-ferrier
And that's great. It's not so much fun for a working programmer though. You
don't want to have to implement an object system over and over again, you want
to use one to write code.

------
brennenHN
I wish I had more time to get better with emacs. I use it all the time and
when I see things like this it makes me love emacs and hate that I don't take
advantage of how deep it is.

~~~
nic-ferrier
That's one of the reasons I wrote this. One thing you could do is write
scripts in it. Or smaller programs.

One thing I'd really like to do is to make a massive index of emacs-lisp code
on github. That would be a fantastic resource.

~~~
chrismonsanto
You mean like <https://github.com/emacsmirror>? :)

~~~
nic-ferrier
No, that's just a list of stuff (there are other really good pointers to elisp
on github too) - I want an index of all the functions and variables used in
the code there, hopefully with a usage index (where is find-file used?). It
would be big data but totally awesome.

------
swah
There is also a important lesson which goes like this: your scripts should
operate on a buffer (even a temporary one) and almost never on strings. Its
generally easier that way because there is so much support from all the
functions already exposed to editing tasks.

~~~
nic-ferrier
Hmmm... I think I disagree with this as well... strings are very very well
supported... it's a little annoying that we don't have a full string lib in
elisp (some of the things here <http://emacswiki.org/emacs/ElispCookbook#toc1>
are missing, but that's why I say you can copy and paste when you need to).

~~~
swah
You rather write something like this (from Emacswiki) operating on strings?

    
    
            (defun kill-whitespace ()
              "Kill the whitespace between two non-whitespace characters"
              (interactive "*")
              (save-excursion
                (save-restriction
                  (save-match-data
                    (progn
                      (re-search-backward "[^ \t\r\n]" nil t)
                      (re-search-forward "[ \t\r\n]+" nil t)
                      (replace-match "" nil nil))))))

~~~
nic-ferrier
it depends on the context... but maybe replace-regexp-in-string would be the
right function to use for strings in this context.

Of course, a lot of the time buffers are really powerful tools to replace
strings. I just don't think your original assertion of "almost never" is
right. Buffers are handy but I use them to replace strings less than 50% of
the time.

------
abecedarius
Is it really the convention to name a some-user class 'some-userc'? Eeeargh --
I can see it's sort of like the established -p convention for predicates, but
there at least it'd be 'some-user-p' instead.

~~~
swah
Since elisp allows it, I find '?' very elegant for predicates.

~~~
abecedarius
I agree, but foo-p doesn't make me go all "wtf?"

