edp:

The two-column feature you're looking for is called follow-mode. So M-x follow-mode RET after you split the window.

The 2C stuff allows you to take a text file which has two columns and edit it naturally. Not a very common thing, but I've used it occasionally after pulling text from a PDF.

I've been getting into Common Lisp heavily lately. Working with Emacs Lisp has always been a great change of pace from daily work in C or Java. Things like map, with-*, and the delightful development environment are great, but the biggest reason is that it's a completely different mindset. Lisp doesn't make you bother with declarations, recompile cycles, or loading a separate debugger.

Common Lisp may not have the extremely portable library called Emacs, but it's a lot faster, and has features which make

My play project is a DVD database. Not like the pathetic ones you see on slashdot, which index the movies and may, if you're lucky, link to Amazon. No, I want a database that fully describes my DVD collection. It'll start with the release (the thing you buy at the store), progress down through the case (Monty Python's flying circus has a box with a bunch of keep cases), through the disc (or as I prefer to call it, the shiny thing), describe the main feature, the extras, the audio tracks available for each, etc. The initial use case is to be able to decide if I want to buy a new edition of something, knowing as much as possible about what I have. Right after that is to let my family know what I have so they don't duplicate them during the holidays.

It's just great to experiment and futz around interactively. For example, here's my proof-of-concept Amazon search:

 (setf result (xmls:parse (net.aserve.client:do-http-request 
    "http://xml.amazon.com/onca/xml3"
  :query `(("t" . ,*associate-id*)
	   ("dev-t" . ,*developer-token*)
;	   ("AsinSearch" . "0439139597")
	   ("KeywordSearch" . "Harry Potter")
	   ("mode" . "books")
	   ("type" . "lite")
	   ("f" . "xml")))))

 (assoc "Asin" (cdr (assoc "Details" (cddr result) :test #'equal)) :test #'equal)

This uses xmls to parse the XML and Portable AllegroServe to talk http. CL may not have the huge quantity of libraries that other languages have, but I'm still happy how easy it was to get together!

forrest:

I'd bet you're running into a stack-size limit. Check ulimit -s to see if you have a limit currently defined. If so, increase the limit or turn it off.

Stack size limits can be a bit tricky to diagnose since the segfault show the line where the variable was defined.

I think people concerned about perfectly duplicating Word's layout should realize a few facts.

Word's layout has changed over the years.

Word's layout depends on the specific metrics of the fonts involved. I believe that the metrics of the usual fonts may have changed slightly over the years.

Word's layout depends on the specific printer driver you are using, since it modifies the font metrics depending on the printer driver. (ISTR there's a way to turn this off recently, so add this to the above.)

Word users exchanging Word documents between each other can't depend on the document looking the same way on each machine. This has been a problem for Word users for years. Since these problems are inherent to the design of Word. A Linux project to exactly duplicate Word's rendering engine will still have problems with a document looking different than it looks to the person who wrote it using Word. That's why I think that it's more important for a Word formatter to try to format things well, rather than try to match a target's evasive maneuvers.

There is a place for a formatter which always makes a document the same way. Word users have been asking about this for years. (WP users too, once it started using Windows, I think.) This is the same reason that Knuth went through such pains to make TeX's output the same wherever, on whatever. But a formatter can't do this and match Word's erratic output.

Ah, the simple joys of free software.

With all the Gnome/KDE/Openoffice/Mozilla megaproject work going on, it's easy to lose track of the real point of the movement. Open source isn't just so huge groups of developers can erect major edifices. That's great! But after the glamorous work is done, free software keeps helping people.

I'm saying this, even though you all know it, because this week has been a good reminder in why I use (as opposed to write) free software.

I recently abandoned my Palm III and switched back to Emacs's diary for my calendrical needs. It's nice, but I found that since the calender view didn't distinguish types of events, I couldn't look at a month and see what's going on in a glance. I fixed that by allowing sexp entries to specify a face, so that I could tell at a glance when I was on-call during a holiday that coincided with someone's birthday. Patch mailed off.

I discovered someone had finally written an Emacs Lisp Z-code interpreter called Malyon. (It's been out a couple years, I must have missed its release.) But it had some problems under Emacs 21. Easily fixed and another patch sent.

This basic plot repeated itself for some more elisp and some other utilities. None of the patches have seen a released version yet, but they've been pretty well received so far. The important thing is there are now some problems that I don't have anymore.