# Slim-Vim ## Future work - compiler note handling - compile defun - change the debug output to be more inline with the Slime messages buffer - macro expanding, insert arglist? - inspector describe - profiling - debugger improvements, restarting, stepping, breaking, interactive evals - documentation support - edit-definition (of the current symbol) - complete symbol? - who calls, who references, who binds, who sets, etc - support *use-dedicated-output-stream* == NIL ## SLIME-DISPATCH-EVENT - incoming and outgoing events route through here - a big case statement that does different things based on the event Continuations - an assoc list of (ID . FUNCTION), *slime-rex-continuations* - when you do :emacs-rex, push a new continuation to the list and send to swank - when you do :return, find the continuation in *s-r-c* by using the ID, and call the function ## Tracing an evaluation (slim-vim::slime-eval-defun) - gets the outer form and evaluates it (slime::slime-interactive-eval) (slime-eval `(swank:interactive-eval ...)) (slime-rex ....) (slime-dispatch-event (:emacs-rex (swank:interactive-eval...))) (:emacs-rex form package thread continuation increments an ID counter pushes a continuation onto an assoc list - continuation is of the form (lambda (result) (destructure-case (:ok ...) (:abort ...))) one of the 2 cases will get called back --------------------------------- Code is passed to Swank, and Slim-vim now exits slime-dispatch-event Is there a possible re-entrant problem here?? (don't think so) Swank replies and slime-dispatch-event catches the result --------------------------------- slime-dispatch-event gets (:return value id) - looks up the assoc list of continuations that have been formed from previous :emacs-rex calls - pulls the continuation off the list and calls it ## BUFFERS --debug-sv-- : for debugging slim-vim itself, and a good place to throw any old crap until we find a better place for it --slim-vim-debug-- : Swank debugger output/interaction. This is what you will use when debugging your Lisp program --slim-vim-inspect-- : inspector buffer ## Stuff to work on - the "glue" file ought to be rolled in somewhere - address all of the TODOs - correctly export the appropriate functions - examine the com sockets and remove the unneeded vars - correctly read Swank's secret - check that packages are getting send to swank properly - understand slime-eval[-async] differences, right now -async is a more general version of slime-eval - delouse buffer-util and ecl-slime.vim ## Slim-vim-REPL What behaviour do we want? Looks like PACKAGE> (+ 1 2) nmode will 1) Eval the current form 2) Print PACKAGE> Result 3) Print PACKAGE> ## BUGS :grep is broken when you are attached to slime - Workaround, use :vimgrep - compiling a file while IO is being directed to SV causes a hang, without any notes. - not true, only when you call a function during compile that causes output! ## Notes for stuff I'm working on Quickfix - can write the content to a buffer and load it with, will jump to 1st error :cb[uffer] [bufnr] - can use lad[dexpr] to add individual errors, may be slow Errorformat determines how the errorbuffer is read %f file name (finds a string) %l line number (finds a number) %c column number (finds a number representing character column of the error, (1 == 1 character column)) %v virtual column number (finds a number representing screen column of the error (1 == 8 screen columns)) From Swank (:message "--> SETQ \n==>\n (SETQ TEST::*B* '(TEST::A (1 2 3) 3 5))\nundefined variable: *B*" :severity :warning :location (:location (:file "/Users/brad/development/lisp/ecl-slime/test.lisp") (:position 95) nil) :references nil :short-message "undefined variable: *B*") Goes to /Users/brad/development/lisp/ecl-slime/test.lisp>95>undefined variable: *B* set efm=%f>%l>%m :set efm=%A%f:%l:%c:%*\\d:%*\\d:, \%C%*\\s%trror:%m, \%+C%*[^:]%trror:%m, \%C%*\\s%tarning:%m, \%C%m <