Emacs Paper from 1981

It's been a while since I read RMS's paper on Emacs. Back in 1981, I still had another 2 years before I even saw my first computer. Reading the paper gives some insight into some of the issues they were trying to solve (real time display, extensibility, portability).

The first thing that came to mind when I first read this paper was that (to an outsider at least) Emacs really hasn't changed fundamentally since 1981 - the basic structures have held up well. I don't see any mention of subprocesses in the original paper, so that's something pretty fundamental that is new (since 1981). Of course the other obvious additions are MULE, image support, fonts, and the graphical interface.

Amusingly, vi was not mentioned in the Other Interesting Editors section. From reading the wikipedia article on vi, it certainly was available (it's a part of the Unix standard).

But what really struck me as interesting and powerful was the decision to use dynamic binding. I'd remembered playing with the differences between dynamic and lexical scoping in my SICP class in college, but never saw a reason to use it. Well, it totally fits when you want to customize Emacs' behavior.

The paper is certainly worth the 10 minutes it takes to read.

Searching GNU From Firefox

When writing up answers for Emacs related questions on stackoverflow.com, I like to include links to the info pages. I got tired of having to go to the gnu site and then do a google site-specific search. I tried looking for a Firefox search plugin that already did that (or something similar), but to no avail.

However, it's pretty easy to write the search plugin yourself. The main page for creating search plugins on mozilla's developer site gives you pretty much all you need to know, except for where to put the xml file. This page shows you that the installation dir is very likely C:\Program Files\Mozilla Firefox\searchplugins.

You can read the documentation yourself, or just check out the snippet of XML I wrote.

Probably the "hardest" part was finding an icon, and the all-knowing google led me to the www.favicon.cc web page, where someone had drawn the standard GNU icon and made it available under a Creative Commons license:

Emacs Tip #29: customizing hippe-expand

I read A Curious Progammer's post on customizing dabbrev - specifically to skip certain regular expressions at the front of words.

I remember customizing it for Tcl to avoid looking at the $ used to dereference variables. But, I no longer use dabbrev, I use the slightly more general hippie-expand. However, hippie-expand doesn't use the dabbrev settings.

So, the question is, can you get hippie-expand to do the same thing? The answer is, "yes" of course.

hippie-expand does things slightly differently - a little cleaner IMO. It uses syntax tables to determine what to skip. And, since syntax tables are set up appropriately for every mode, the skipping does what you want w/out having to potentially customize a regexp for each mode.

Syntax tables are Emacs' way of encoding the syntactic use of each character in a buffer, and this knowledge is used for motion and regular expressions. That's how forward-word has reasonable meaning in the various programming modes, text mode, shell mode, etc. Similarly, the syntax tables define list motion.

The syntax table has the basic character types: whitespace, punctuation, word, symbol, open/close parenthesis, string, comment start/end, etc. For example, the alpha-numeric characters are generally word constituents. In html-mode the <> symbols are matching parentheses, but in most other programming modes they are punctuation characters.

The variable you set is hippie-expand-dabbrev-as-symbol, which defaults to t. Basically, if non-nil, hippie-expand will try to expand the word under the point including symbol characters, which is not what I personally want. I want to only expand the word characters under my point, so I've set it to nil.

(setq hippie-expand-dabbrev-as-symbol nil)

dot-emacs trickery (emacs-fu)

It's been a while, and to be honest, emacs-fu has been doing such a great job putting up useful snippets of Emacs information...

He just put up a question asking for folk's favorite dot-emacs tricks. I added my two cents with:

(defun tj-find-file-check-make-large-file-read-only-hook ()
 "If a file is over a given size, make the buffer read only."
 (when (> (buffer-size) (* 1024 1024))
   (setq buffer-read-only t)
   (buffer-disable-undo)
   (message "Buffer is set to read-only because it is large.  Undo also disabled.")))
    

(add-hook 'find-file-hooks 'tj-find-file-check-make-large-file-read-only-hook)

Emacs Tip #28: e-blog

There are a number of different packages purporting to enable blogging from Emacs, but most people (including myself) have failed to get any of them to work.

I recently heard about: http://code.google.com/p/e-blog/, as a simple blogging package specifically for blogger.

This is my first post.

Note: It does depend on curl.

stackoverflow.com

If you read Coding Horror or Joel On Software, you already know about stackoverflow.com. In a nutshell, it's a place where you can ask coding questions and receive answers quickly. You can also participate by voting answers up/down and answering questions.

stackoverflow.com works really well, the overall design is very simple, clean, and easy to use.

The emacs community there is pretty small, but questions do come up now and then. In general the answers are fairly good (I think mine are stupendous, feel free to look at them and vote them up).

Like any good (modern) web page, this one has plenty of RSS feeds. This is the feed I use to watch questions tagged emacs elisp emacs-lisp dot-emacs.

A guided tour of Emacs

I recently came across the GNU page: A guided tour of Emacs. It is a gem of an introduction to Emacs. Unlike the help distributed with Emacs (tutorial, FAQ, *info* pages), this tour does a good job illustrating the wide variety of Emacs capabilities, and I think it is much more motivating for a newbie than anything else I've seen.

Emacs Tip #19: Startup Options (-q)

The most useful two options I've found for starting up emacs are:

    -q

and

    -debug-init

The first disables the loading of your .emacs and default.el files, which is handy when you want to differentiate between problems in your .emacs file and problems outside (.Xdefaults, site specific .emacs, etc.).

The second gives you a backtrace when any error happens during loading of your .emacs file. While it doesn't often pinpoint the exact line where things went wrong, it usually gives you a clue as to where to start looking for problems.

For all options, read the manual here: Initial Options - GNU Emacs Manual

Emacs Tip #17: flyspell and flyspell-prog-mode

Being in front of the computer hasn't helped my spelling because it's so easy to let the computer catch and fix the spelling errors for me. Of course Emacs has spell checking (M-x spell-{buffer,region,string,word}), but what is really handy is spell-checking as you type.

Enter flyspell.

flyspell is a minor-mode, so enabling it only causes spell-checking in that buffer, so it's handy to add the hooks to turn it on for the modes you deem appropriate (mail messages, text files, etc.). But wait, you do most of your work programming, right? Just turn on flyspell-prog-mode, and only your comments and strings will be checked for spelling errors.

It has the standard installation - only the major entry point is the routine 'flyspell-mode where the filename is "flyspell.el", so you need to tell Emacs to look for that appropriately. Here's what I use to enable flyspell and turn it on for a couple of different modes.

(autoload 'flyspell-mode "flyspell" "On-the-fly spelling checker." t)
(add-hook 'message-mode-hook 'turn-on-flyspell)
(add-hook 'text-mode-hook 'turn-on-flyspell)
(add-hook 'c-mode-common-hook 'flyspell-prog-mode)
(add-hook 'tcl-mode-hook 'flyspell-prog-mode)
(defun turn-on-flyspell ()
   "Force flyspell-mode on using a positive arg.  For use in hooks."
   (interactive)
   (flyspell-mode 1))

Emacs Tip #16: check-parens

Ever had trouble finding a mismatched parentheses in a file? Of course not, you don't make mistakes.

But, if you do, you can use the built in functionality of M-x check-parens

The documentation is here Parentheses - GNU Emacs Manual

It doesn't pinpoint the problem as closely as I would have hoped in some modes, but it's better than nothing.

Interview-1

I've written before about interviewing, but I think there's a topic people have ignored, namely that people conducting interviews forget (in my vast experience of employment in 2 companies) is that a part of the purpose of the interview is to sell the group/company to the interviewee.

Shortly after the post in August, a friend of mine started looking for jobs, he interviewed at companies X and Y, and his experiences were very different.

Let me compare and contrast the two interviews:

At company X, he was underwhelmed by the technical lead for the job (the guy is nice, but somewhat soft-spoken, so not a lot of energy/excitement), and the questions posed by all the interviewers were pretty shallow. In other words, the questions were like, "write a routine to do sorting", which he did, and then they moved on to the next question - no further investigation of why he chose that, how might he optimize it, etc. etc. etc. It sounded kind of like watching an interview on TV where the questions were all 'yes' or 'no' questions.

At company Y, the questions were very often 'deep' questions, where the initial answer was picked apart and explored. The questions also seemed to be a little more interesting and challenging - one of the guys asked my friend how he might approach a problem that the guy had been working on that entire week.

Needless to say, my friend decided against working at company X and was very tempted by company Y.

I recall my interview at Mentor, and it was somewhat similar to my friend's at company X, only I wasn't asked to write any code. I did bring some samples of what I'd written and offered them to the hiring manager. I presume the interviewers liked what they saw in me, but I was concerned because I expected to be asked to show some level of competence in the job for which I was interviewing (a programmer).

I always figured that if you're interviewing for a job at an auto-repair shop, you'd be expected to poke around an engine and show some competence. The same thing should go for a programming job. And, wouldn't you be a little concerned if you knew your mechanic didn't require a competency exam before hiring his mechanics? (See raganwald's hiring a juggler post.)

So remember, the quality of the interview you provide influences how the interviewee views the company.

Emacs Tip #13: browse-kill-ring

The kill-ring. You know about the kill-ring, right?

C-h i m emacs RET kill ring RET

Ok, now you know about the kill-ring, it is basically a list of all the chunks of text that have been cut (C-w) (or just saved using M-w). The basic interaction with the kill-ring is:

C-y (aka "yank" aka "paste")

After you've pasted text, if you didn't want that, but an earlier chunk of text, the key M-y will cycle through the earlier chunks, replacing what was just pasted with the earlier text.

If that's too much for you to handle, you can browse the entries in the kill-ring and paste them in (more than one if you want).

To get it, go to the wiki and download it.

To install and use, do the standard download, load-path manipulation, and:

(require 'browse-kill-ring)
M-x browse-kill-ring
[edited to correct the cut/paste commands]
[edited to fix broken link]

Teach The Hard Stuff

I read the Coding Horror entry on how to teach Computer Science the other day...

Coding Horror: How Should We Teach Computer Science?: "If we aren't teaching fundamental software engineering skills like deployment and source control in college today, we're teaching computer science the wrong way. What good is learning to write code in the abstract if you can't work on that code as a team in a controlled environment, and you can't deploy the resulting software? As so many computer science graduates belatedly figure out after landing their first real programming job, it isn't any good at all."

I scanned the comments and most people talked about CS versus SE (Software Engineering), or what they think is most important to teach. I agree with the narrow point that computer science is different than software engineering - the former teaches the theory and fundamentals of computers, languages, and programming, while the latter focuses on how to engineer software for the real world.

To a large extent CS and SE are orthogonal. Knowing how to write code that can compile on 11 platforms, versus understanding why a regular expression cannot be used to match parenthesis are two completely different issues.

The difficulty with coming up with the "truly important" concepts that should be taught in school is that the software industry is too diverse to be able to put in a nutshell. Take, for example, Jeff's idea that "computer science students should develop software under conditions as close as possible to the real world" just doesn't make sense. What real world?

I've, thankfully, been gainfully employed as a software engineer for 12 years, and I've never had to worry about software distribution, and there are large numbers of people who have never had to think about that. Why? Because it was taken care of by other people - I simply abstract away that problem as not something I had to solve. So how would that lesson have helped me?

But even if you wanted to teach about software distribution, what kind of distribution? Should the students have to deal with a wide variety of PC builds (Windows2K, Vista, Me, XP)? What about Mac? And the ton of flavors of Unix and all their varieties? What about 32 versus 64 bit platforms? What would this really teach students? Distributing software is a pain. Fine, lesson taught, but why have to go through this for every class? Does everyone in your company know how to distribute the software you produce?

My point isn't for or against teaching about distribution of software. Almost any one topic under the umbrella of CS or SE fails to apply to all of the software industry. No matter what you are taught, you are going to learn things you never use, and you are not going to learn things you need to know to do your job.

So, what should be taught?

This reminds me of the time I asked a professor what I should study in my last year or two - as I only had a couple of slots free for non-mandatory courses. I was specifically asking about taking math versus computer science classes (I was a double major), and he advised math. Why? Because math is hard.

So we should teach math?

Um.... not quite the point.

I think that school is a good time to learn the fundamentally difficult concepts. Hopefully you'll always be surrounded by intelligent, inquisitive peers and knowledgeable mentors, but the chances are school is your best bet for being immersed in that kind of environment. Think of school as a petri dish, sure, mold can grow anywhere, but it grows really well in a petri dish.

So now software is mold?

University should teach fundamentals and fundamentally difficult concepts. So things like: data and procedural abstraction, algorithmic complexity, data structures, algorithms, and what makes up this computer (OS, hardware, compiler, network). Hmmm... sounds like the course requirements for my CS degree.

No software engineering basics?

That being said, it would have been a heck of a lot easier to do some of the course work had I known more about how to use a text editor, version control, a debugger, logging, unit testing, or (gasp) an IDE. I would definitely have appreciated some introduction to those early on. But early on the projects are so small that none of those are important and would just get in the way. It's the classic chicken-and-egg problem.

So you want both CS and CE taught?

What I really want from a new college graduate is someone who can think for himself, and has the intellectual curiosity to continually improve.

Version control, any build system, testing harness, language, or software distribution system is (IMO) much easier to learn than discerning algorithmic complexity. So, if one has to make a choice between the two, I'd choose the more difficult subject, algorithmic complexity. Some of the comments argued that people don't tend to ever learn version control, so it should be taught in school. To which I would respond, if they are the kind of person who only ever learned it superficially in the real world, they would have only learned it enough to pass the class.

Teach the hard stuff in school, and, where possible, teach software engineering skills to help the student thrive while in school.

Back to the idea of developing software at school in conditions that match the 'real world'. The real world is full of noise. I'd much rather learn the subject matter than be subjected to compiler bugs, platform differences, whiny customers, incomplete specifications, etc.

I guess it boils down to the first CS class I took in college. I loved the class, and I still think it the best introductory CS class available. Why? Because in one semester you go from knowing next to nothing about CS to learning data structures/algorithms/complexity analysis and writing a interpreter, a CPU simulator, and a compiler. One semester, and you're exposed to basically all of computer science - and not just superficially.

Scheme? You want to force me to (parse (all (the (parentheses))))?

Grow up, look past the language. Look at the concepts taught. If you want to rewrite the book using Ruby or whatever, be my guest. If the result is a class that can still fit into a semester, all the power to you. The point of using Scheme was that the language is taught in one lecture, and after that you get to learn the interesting things. Try teaching meta-programming to C++ novices (hell, try teaching it to 99% of the software community).

Yeah, but it's just a toy interpreter/compiler/CPU...

If you actually look at what is taught, you have a supremely flexible interpreter/compiler/CPU simulator, and you can vary the semantics of the language, compiler optimizations, and hardware configurations. You can explore the intricacies of each to whatever extent you desire.

I've never seen that much information packed into such a concise form that is accessible to first year students.

Whatever is taught to computer science students should be taught with a focus on that subject. Just like you should remove distractions that drag your developers down, you should remove distractions from the subjects taught in school. If you want to teach about developing software in the real world, then make a class or two that does that, or provide internships, or contribute to open source projects. If something doesn't help the student learn the subject, it gets in the way.

Emacs Tip #10: sig-quote (intelligent, random signatures)

Way back when I first started using Emacs, I read email with it. A friend had some script which modified his .signature file with a random quote every 30 seconds. I thought that was kind of neat, but I wanted every email to get its own, random, quote. At the time I didn't know how to get a random number in a simple shell script, so I started writing something using Emacs directly.

A random signature wasn't enough though, I then wanted to be able to have different categories of quotes and send different people quotes from those different categories. From the documentation:

;; This mode is designed to allow a user to have quotes appended to
;; their mail and news posts according to whom/where the mail is
;; being sent.  For example, one might wish to have "insightful"
;; quotes sent to Prof. Apple, and "crude" quotes to your brother
;; Sam.  With this mode, upon sending a piece of mail, the email
;; addresses are scanned (this includes the To:, CC:, and BCC:
;; headers), and an appropriate quote is inserted into the letter.

Thus began my Emacs fascination.

You can download the source here.

9 Tips for the aspiring Emacs playboy | LispCast

Ha, saw this today and had to laugh because of the images. They are pretty good tips.


9 Tips for the aspiring Emacs playboy

The only other tip I'd add would be to subscribe to this blog.