From 3255eac184613601aa11b59fd3afd2d5ba13d12e Mon Sep 17 00:00:00 2001 From: Jose Antonio Ortega Ruiz Date: Fri, 26 Jan 2018 01:39:30 +0100 Subject: [PATCH] New HACKING file --- HACKING | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 HACKING diff --git a/HACKING b/HACKING new file mode 100644 index 0000000..e357fd3 --- /dev/null +++ b/HACKING @@ -0,0 +1,26 @@ +## How to support a new Scheme implementation + +Geiser works by running an instance of a REPL, or remotely connecting +to one, and evaluating the scheme code it sees there. Then, everytime +it needs to perform some operation (like, say, printing autodoc, +jumping to a source location or expanding a macro), it asks the +running scheme instance for that information. + +So supporting a new scheme usually means writing a small scheme +library that provides that information on demand, and then some +standard elisp functions that invoke the procedures in that +library. + +To see what elisp functions one needs to implement, just execute the +command `M-x geiser-implementation-help` inside emacs with a recent +version of geiser installed. And then take a look at, say, +geiser-guile.el or geiser-racket.el for examples of how those +functions are implemented for concrete schemes (those are the most +featureful implementations we have, so perhaps it's easier to begin +with something like geiser-chicken.el or geiser-chibi.el). + +Not all schemes can provide introspective information to implement all +the functionality that geiser tries to offer. That is okay: you can +leave as many functions unimplemented as you see fit (there is even an +explicit list of unsupported features), and geiser will still know how +to use the ones that are implemented. -- 2.11.4.GIT