jpayne@flam.Eng.Sun.COM (Drummer Boy) (10/13/90)
Hi there, would some nice person be willing to explain to me the model for LISP execution inside GNU emacs? What do I mean? Well, is the editor always running inside a lisp context? Or is the main loop written in C, and does it sit there reading the keyboard, looking up the keys in the various keymaps, and checking on the type of the thing it's trying to execute? And when that thing is a piece of LISP code, it just fires up an interpreter to execute it? What happens if there is an error while executing a piece of LISP code? If the editor is running LISP the whole time, there must be some main loop that sits there reading and dispatching keystrokes, right? So when there's an error, is an error-handler fired up which read and dispatches more keystrokes, but also lets you look around at the state of the world? Does emacs have multiple LISP threads at any given time? Is there a way to arrange to have a piece of LISP code executed when output appears from a process? Does EMACS stop what it's doing and fire up that piece of LISP code, and if that piece of code sits there in an endless loop, is EMACS hung until some sort of timeout occurs? I'm just trying to get a feel for how this whole thing is put together. I never thought about it carefully before now. Thanks for any info. Jonathan Payne
jbw@bucsf.bu.edu (Joe Wells) (10/14/90)
Hi there, would some nice person be willing to explain to me the model for LISP execution inside GNU emacs? What do I mean? Well, is the editor always running inside a lisp context? Yes, well, sort of. Or is the main loop written in C, and does it sit there reading the keyboard, looking up the keys in the various keymaps, and checking on the type of the thing it's trying to execute? Yes. However, the main loop is simply the function "recursive-edit", which may itself be called from lisp code. And when that thing is a piece of LISP code, it just fires up an interpreter to execute it? It ends up calling "eval", which I suppose is equivalent to "firing up an interpreter". What happens if there is an error while executing a piece of LISP code? A signal is raised using "signal". The signal may be caught by an enclosing "condition-case". Otherwise, if the variable "debug-on-error" is non-nil, the value of the variable "debugger" is called, if it is non-nil. Otherwise, a the tag "top-level" is thrown using "throw". If the lisp code does not have a corresponding catch, the tag is caught by a top level "catch", which prints an error message and reinvokes the main loop. If the editor is running LISP the whole time, there must be some main loop that sits there reading and dispatching keystrokes, right? Yes, it is a C function called "command_loop_1", which is called by "recursive-edit". See the file src/keyboard.c for more info. So when there's an error, is an error-handler fired up which read and dispatches more keystrokes, but also lets you look around at the state of the world? It can be, if the variables "debug-on-error" and "debugger" are non-nil. Does emacs have multiple LISP threads at any given time? No, no saved stacks. Is there a way to arrange to have a piece of LISP code executed when output appears from a process? Yes. Does EMACS stop what it's doing and fire up that piece of LISP code, and if that piece of code sits there in an endless loop, is EMACS hung until some sort of timeout occurs? Yes and no. You can type C-g which will almost always interrupt whatever is executing. -- Joe Wells <jbw@bu.edu>