do not edit — generated by btf.
git.druid.rocksindexdruid520radiumlib/radium.lisp

lib/radium.lisp


;;; radium.lisp, call back into the running radium daemon from sbcl
;;
;; item 14: there's no way for common lisp (or scheme, radium.scm)
;; running in its own process to reach into emacs's own display/
;; keymap/buffer internals directly - no bridge exists for that in
;; either direction. what already exists is ~/.radium.ipc
;; (radium-ipc.el, item 12): a real fifo the running daemon reads
;; elisp forms from and evals, one per line. this file is that same
;; channel's far end - load it into a real slime repl (M-x slime,
;; then M-x slime-load-file on this file, or just (load "path...")
;; at the sbcl prompt) and (radium-ipc "...") sends a real elisp form
;; into the running daemon from your own cl code: open a buffer,
;; insert a computed result, define a whole new command - not just
;; print to slime's own repl buffer.
;;
;; fire-and-forget, same as radium-ipc.el's own design: the result
;; goes to the daemon's *Messages*, nothing comes back down this pipe.
;; if you need a real return value, emacsclient --eval (or M-x slime-
;; eval-... from the emacs side) already is that - radium-ipc was
;; never meant to replace it, see radium-ipc.el's own header.
 
(defun radium-ipc (form)
  "append FORM (a string holding one real elisp form) to
~/.radium.ipc. errors (radium-ipc.el not loaded in the running
daemon, so the fifo doesn't exist yet) surface as a real file error,
not a silent no-op."
  (with-open-file (s (merge-pathnames ".radium.ipc" (user-homedir-pathname))
                      :direction :output
                      :if-exists :append
                      :if-does-not-exist :error)
    (write-line form s)
    (finish-output s)))
powered by btf.