Interesting – there is another guy talking about how people should focus their efforts on fixing and improving core libraries rather than writing their own code.
Documenting Emacs also improves your Emacs Lisp skills because you’ll likely be reading other hacker’s Emacs Lisp code. Most important of all you’ll be working on existing code for Emacs rather than making more when it is not entirely necessary to reinvent the wheel.
I guess my last two posts, which have been more self-indulgent rambling than code demonstration, have muddied the purpose of this blog. Let me try and explain where I’m coming from. Then in future posts I can get back to the important thing which is talking about code.
What do I want [from this blog]?
I don’t want to become a super emacs coder primarily because the effort required is too great. There is no documentation other than the code that gets me from where I am to there. And to be honest I don’t care about hacking on emacs core.
My [unrealistic?] goal is to get more people to write emacs lisp. Not necessarily good emacs lisp but any emacs lisp. Why? Because that leads to more discussion, more libraries, better documentation and more people writing emacs lisp. It is a virtuous circle.
And if you don’t get anyone in on the first rung of the ladder, for sure you won’t be getting new guys hacking on the core libraries either.
What have I done about that?
I’ve written about a couple of libraries and APIs that are available and techniques to solve simple emacs problems that are accessible to any programmer, not just one who is steeped in the emacs way.
And I think I’ve done a pretty good job.
If I want to know how to use overlays, and even what they are where are the best places to look (the answer – my lens which covers a practical use of emacs overlays). If my blog didn’t exist, the only option people have to learn about this stuff is to read some fairly dry documentation or the code itself.
What about comint, my favourite library? Again, either my db mode lens or my comint post. An example that is not mine: emacs fu is the best place to learn about custom menus and numerous other little emacs features.
Unfortunately a blog isn’t an ideal place for documentation. But I do keep the list of archives up to date. And one day I’ll make a half decent index page.
Other places to go for a good introduction to emacs are Xah Lee’s Emacs stuff and of course the Emacs Wiki.
Do you want to know why there are so few elisp programmers? Its because emacs is "self-documenting". That basically means "we can’t be bothered to write documentation".
Take a look at perl, php, python. The documentation is good, extensive and centralised and there are numerous examples and discussions of how to do things. And perhaps not coincidentally, all of those languages are orders of magnitude more popular than elisp. That should be the model to aim at.
And a good start might be to translate parts of PLEAC to elisp. I’ll take a look at that.
Jared,
A very constructive answer to those bloggers which chimed into the discussion about the apparently precious resource of developer time!
As a non-lisper, a recent Emacs convert, and a regular reader of your blog, I say, keep on keepin’ on. Whatever else might be worth doing in the Emacs world, those early rungs on the ladder are worth helping people with.
I’m really not much beyond making customizations to my .emacs, but it’s clear to me after 4 or 5 months of Emacs use, that I eventually need to start up the ladder. The pains of Emacs (shall we not admit that their are some?!) are only outweighed and overcome by its programmability. And I suspect that you don’t need to get to the top of the ladder to dispense with many of those pains.
Thanks.
Hi. I like your posts in the Planet Emacsen stream. Keep up the posts and the open comments section.
One of the things I want to write in Emacs Lisp is a Make-like system to prep my .emacs.d directory to make autoloads and byte-compiled files. Why not use GNU Make? Well that’s not installed on Windows. I use Ruby rake for now, but I want to get rid of that dependency. I haven’t gotten very far with this project though because of time constraints, lack of full Emacs Lisp grok, and I already a solution that is “good enough”. I wonder if this wheel has already been invented.
@Scot – thanks for the comment. You’re right that you don’t need to be an expert to significantly improve your own emacs experience. Almost all of the niggles that I have with emacs have been resolved.
Now that I’ve fixed my gripes, one of the main activities that I’m still doing at the moment is moving external utilities into emacs where it makes sense to do so to avoid the context switch that I have when I need to use an external shell.
@Piyo – glad to hear you like my posts
What does your current make system do? Using rake is probably the best idea (pragmatic and saves reinventing the wheel), but if you’re not rebuilding dependencies and simply comparing creation dates then you probably need to do the following:
get the list of files with file-expand-wildcards
compare the modified time (nth 5 (file-attributes *file*)))
with the current-time.
You can’t compare the times directly but will need to convert to a floating point first using time-to-seconds.
(Details found trawling through files.el and time-date.el)
I hope this helps.
“Do you want to know why there are so few elisp programmers? Its because emacs is “self-documenting”. That basically means “we can’t be bothered to write documentation”.”
So you’re saying that Emacs is primarily documented through doc-strings? That’s obviously wrong, and does all those people injustice who actually bothered to write up a *ton* of (mostly) well written documentation, which you can easily access through C-h i. The main reason that there are so few elisp programmers is because there are so few Emacs users.
“Take a look at perl, php, python.”
That’s an unfair comparison. Keep in mind that Emacs Lisp is still a pretty old, *very* reduced LISP dialect, aimed at extending Emacs. It is not (and was never) meant as an universal scripting language.
No I’m not saying that, (although I must say when I’m looking for how to do something the first thing I reach for is apropos). When I’m talking about this self-documenting excuse being annoying I’m not referring to the documentation that exists I’m talking about the documentation that doesn’t exist.
For example, the find-file api. Now, if I want to solve a file related problem, I’ll waste my time rooting around in files.el. But the other 100 guys who could have used emacs to solve the same problem, they’re going to reach for python, or ruby.
I’m aware of the info documentation within emacs and whilst I appreciate it, it doesn’t come close to a nice indexed API reference.
And I think it is a fair comparison. Emacs Lisp can solve many problems in a comparable amount of code to other scripting languages and some expect-like stuff even better (using comint of course).
And the limitedness of emacs-lisp is exagerated. Sure, it isn’t the nicest language going and I kinda miss lexical variables, proper closures, threads and all that other great stuff, but it does have a lot of libraries. And if one of those libraries has already solved 90% of your problem it is a great choice.
“For example, the find-file api. Now, if I want to solve a file related problem, I’ll waste my time rooting around in files.el.”
M-x elisp TAB find-file RET
I very rarely dig around in Emacs core libraries. Most stuff is very well documented in the reference manual. What actually is missing is a way to quickly find related functions, which might begin with a different name. There has been some discussion on Emacs devel to create function tags for this purpose, which would be very helpful indeed.
“And I think it is a fair comparison. Emacs Lisp can solve many problems in a comparable amount of code to other scripting languages and some expect-like stuff even better (using comint of course).”
Emacs Lisp, together with the Emacs libraries, is very well suited for problems which deal with editing text (in the broadest sense!). Other stuff – well, often not so much (CGI? Network protocols aside from those dealing with mail? Numerics (e.g. like NumPy)?)
And Emacs Lisp has very serious limitations which makes writing bigger applications much harder. Just take a look at complex elisp projects like CEDET, and you’ll see that a good portion of the code just deals with extending elisp (e.
Oops – I somehow triggered the submit button. Anyway, I don’t want to drag this on forever. What I wanted to mention is CEDET’s CLOS-like object system, EIEIO. I hope this will make its way into Emacs core eventually. My biggest gripe with elisp however is the global name space, and I doubt this can ever be solved.
Anyway, please keep up the good work in your blog. I enjoy reading it!
Actually the function I was looking for was file-expand-wildcards. If I had guessed wildcards I would have found it more easily. The php documentation and perl documentation groups all file related functions together so I don’t need to guess.
Anyway, point taken about the emacs lisp weaknesses. Sometimes I forget that there are problems that people are solving problems other than mine (I’ve found that many people have a similar blindness)
However, although CGI and servers might be a little inefficient in Emacs Lisp I’ve found calc quite nice for numerical problems, and I’m sure that there is a parigp mode if that is not enough. And I also suspect the client networking is good although I haven’t looked into it.
I’ll take a look at better look at eieio.
Anyway, thanks for appreciating my blog. I appreciate it
> What does your current make system do?
Two main things, creates auto-autoloads.el files and compiles all private *.el files.
For the former, I overload the auto-autoloads creation function so that it does not save the date-time stamp so that I can check in that file to my version control system. The command looks like this: (stuck in Ruby, hey)
cmd = [ getEmacsApp(), "--no-init-file", "--no-site-file", "--multibyte",
"-batch",
"--eval", '(setq load-path (cons "." load-path))',
"-l", "autoload",
"--eval", "(setq generated-autoload-file (expand-file-name \"#{AUTOLOADFILE}\"))",
"--eval", "(setq make-backup-files nil)",
# Do not write the date in the section header so that source
# control does not pick up file times as a change.
"--eval", "(defadvice autoload-insert-section-header " +
"(before rewrite compile activate) " +
"(ad-set-arg 4 '(0 0)))",
"-f", "batch-update-autoloads" ]
# omitted: add the target path to cmd
system( *cmd ) # create it
Pro: Can just checkout out my .emacs.d from the VCS and my autoloads are working from the get-go.
Con: Emacs goes into an infinite loop when refreshing an already existing auto-autoloads.el file. Workaround, just delete the file before trying to refresh it.
One troubling thing is the non-portable way that Emacs packaged software like org-mode or emacs-w3m will use to compile the *.el files. I want Emacs (or some Emacs Lisp script) to coordinate the byte-compiling instead of GNU Make.