Subject: Re: LispWorks with ILISP (Was: OK, CLIM it is. Now my options are...) From: Erik Naggum <email@example.com> Date: Sat, 17 Nov 2001 00:43:33 GMT Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * Erik Haugan <email@example.com> | I've seen people mention this, but I don't really get what it means. | What could you do with a multithreading ILISP? Wouldn't it require a | multithreading Emacs? I guess it has to be seen in use to be considered useful. E.g., you could do a large compilation in another thread and not impact symbol completion, which, incidentally, would not impact any work in progress in the listener where you requested symbol completion. All compilations from Emacs could be performed in their own threads because the Common Lisp system would never know how long they would take to complete. The most user-visible feature is that you can have multiple interaction buffers, or "Lisp listeners". Emacs is not multithreaded, but each buffer that talks to a subprocess can perform I/O "simultaneously". I thought you had played with Allegro CL and the Emacs-Lisp Interface, but if not, it is hard to see from the documentation how this can be used profitably and conveniently. The Emacs function fi:open-lisp-listener is a good start to get a new listener. Using M-x fi:compile-file, etc, is also more convenient than giving the commands directly to the repl, despite with the :cf shorthand. Both menus and keybindings exist for many of these useful functions. It takes some getting used to, since the whole interface is built on a fairly old version of the comint package, but it is well worth it. /// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.