diff options
author | jao <jao@gnu.org> | 2020-07-19 22:41:22 +0100 |
---|---|---|
committer | jao <jao@gnu.org> | 2020-07-19 22:41:22 +0100 |
commit | 847d2ad4c6da462c26c50af1ef7d9cd697f3a5d2 (patch) | |
tree | 29cdda38fe12e399e36830bd25bd7ac5cb83011e /HACKING | |
parent | 02e228f312483fc78af1c2a1e93f706f774788fa (diff) | |
download | geiser-847d2ad4c6da462c26c50af1ef7d9cd697f3a5d2.tar.gz geiser-847d2ad4c6da462c26c50af1ef7d9cd697f3a5d2.tar.bz2 |
scheme and autotools removals
The plan is to have geiser-core contain only, well, the elisp core
engine. The autotools scafolding is no really worth it, so it's gone
too (and in the process, i'll look younger).
Diffstat (limited to 'HACKING')
-rw-r--r-- | HACKING | 26 |
1 files changed, 0 insertions, 26 deletions
diff --git a/HACKING b/HACKING deleted file mode 100644 index 5be4cb2..0000000 --- a/HACKING +++ /dev/null @@ -1,26 +0,0 @@ -## 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, every time -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. |