#Q 4.2-1) How can I open a stream to an emacs buffer?
#Q 4.2-2) How can another stream be used for background output instead of
creating the *background-interaction* buffer?
#Q 4.2-3) How can arbitrary elisp code be run from lisp?
#Q 4.2-4) Is there a way to programmatically determine if the emacs-lisp
interface connect has been established?
#Q 4.2-5) How can I tell if lep had a problem?
Q 4.2-1) How can I open a stream to an emacs buffer?
A 4.2-1) Consider the following:
USER(25): (with-open-stream (*query-io* (lep:make-editor-listener-stream)) (y-or-n-p "Is today Wednesday?? ")) T USER(26):
When this was evaluated, a *background-interaction* Emacs buffer popped up. I answered the question `y', so the form returned T. You may have to bind more or different stream variables to the stream object, of course, depending on what you actually do with the popup buffer.
If you want to name the buffer, do this:
(setq s (lep:make-editor-listener-stream :name "foo"))
A 4.2-2) You can give the variable
lep::*stream-for-background-output*
a value which is the stream to which the output should go, excl:*initial-terminal-io*, for example. Doing so may also affect various emacs-lisp interface commands, of course.
Q 4.2-3) How can arbitrary elisp code be run from lisp?
A 4.2-3) The ACL function lep::eval-in-emacs takes a single string argument which is read and evaluated by the emacs elisp interpreter. For example,
(lep::eval-in-emacs "(message \"foo!\")")
prints ``foo!'' in the minibuffer. lep::eval-in-emacs is synchronous and reads/evals only one form from the string. In other words,
(lep::eval-in-emacs "(foo)(bar)")
will not evaluate both forms, but just the first (foo). lep::eval-in-emacs returns one value, the value returned by the elisp form.
A 4.2-4) Yes, the function lep:lep-is-running returns a non-nil value if the connection has been established. If you want to make sure lep is running, call (lep:ensure-lep).
Q 4.2-5) How can I tell if lep had a problem?
A 4.2-5) There are several lep conditions defined:
lep:lep-error inherits from simple-error and the root of the next two errors. If you just want to establish a handler for any lep problem, this is the thing to handle.
More specifically:
lep:no-lep-connection is signalled when (and only when) code calls (lep:ensure-lep), and there is no connection with an emacs.
lep:lep-operation-aborted is signalled whenever lisp expects lep to return information from emacs and is disappointed.
Unfortunately, several internal errors do not obey the condition protocol, and none of the above conditions have useful slots.
© Copyright 1998, Franz Inc., Berkeley, CA. All rights reserved.
$Revision: 1.1.2.6 $