From 847d2ad4c6da462c26c50af1ef7d9cd697f3a5d2 Mon Sep 17 00:00:00 2001 From: jao Date: Sun, 19 Jul 2020 22:41:22 +0100 Subject: 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). --- HACKING | 26 -------------------------- 1 file changed, 26 deletions(-) delete mode 100644 HACKING (limited to 'HACKING') 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. -- cgit v1.2.3