summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJose Antonio Ortega Ruiz <jao@gnu.org>2010-08-14 21:48:10 +0200
committerJose Antonio Ortega Ruiz <jao@gnu.org>2010-08-14 21:48:10 +0200
commit4c25551e639bb19a60211d30e6c7adb2bc51c59e (patch)
treec91a581510c5ed9dca8dc8dc91ac04db32696388
parent739dde06bdd997995873fcd59f2c1cc1d2976aef (diff)
downloadgeiser-chez-4c25551e639bb19a60211d30e6c7adb2bc51c59e.tar.gz
geiser-chez-4c25551e639bb19a60211d30e6c7adb2bc51c59e.tar.bz2
New restart repl command and a bit more docs.
-rw-r--r--doc/fun.texi29
-rw-r--r--elisp/geiser-mode.el12
2 files changed, 41 insertions, 0 deletions
diff --git a/doc/fun.texi b/doc/fun.texi
index 13c5c72..71490d5 100644
--- a/doc/fun.texi
+++ b/doc/fun.texi
@@ -294,6 +294,35 @@ with all supported Schemes, no strings attached.
@node Evaluating Scheme code, Jumping around, Documentation helpers, Fun between the parens
@section Evaluating Scheme code
+One of Geiser's main goals is to facilitate incremental development. You
+might have noticed that i've made a big fuss of Geiser's ability to
+recognize context, by being aware of the namespace where its operations
+happen.
+
+That awareness is specially important when evaluating code in your
+scheme buffers, using the commands described below. They allow you to
+send code to the running Scheme with a granularity ranging from whole
+files to single s-expressions. That code will be evaluated in the module
+associated with the file you're editing, allowing you to redefine values
+and procedures to your heart's (and other modules') content.
+
+Macros are, of course, another kettle of fish: one needs to re-evaluate
+uses of a macro after redefining it. That's not a limitation imposed by
+Geiser, but a consequence of how macros work in Scheme (and other
+Lisps). There's also the risk that you lose track of what's actually
+defined and what's not during a given session. But,
+@uref{http://programming-musings.org/2009/03/29/from-my-cold-prying-hands/,in
+my opinion}, those are limitations we lispers are aware of, and they
+don't force us to throw the baby with the bathwater and ditch
+incremental evaluation. Some people disagree; if you happen to find
+@uref{http://blog.racket-lang.org/2009/03/drscheme-repl-isnt-lisp.html,
+their arguments} convincing, you don't have to throw away Geiser
+together with the baby: @kbd{M-x geiser-restart-repl} will let you
+restart the REPL as many times as you see fit.
+
+For all of you bearded old lispers still with me, here are the commands
+performing incremental evaluation in Geiser:
+
@node Jumping around, Geiser writes for you, Evaluating Scheme code, Fun between the parens
@section Jumping around
diff --git a/elisp/geiser-mode.el b/elisp/geiser-mode.el
index 083d90a..d786b1b 100644
--- a/elisp/geiser-mode.el
+++ b/elisp/geiser-mode.el
@@ -164,6 +164,18 @@ With prefix, try to enter the current's buffer module."
(interactive)
(geiser-mode-switch-to-repl t))
+(defun geiser-restart-repl ()
+ "Restarts the REPL associated with the current buffer."
+ (interactive)
+ (let ((b (current-buffer)))
+ (geiser-mode-switch-to-repl nil)
+ (comint-kill-subjob)
+ (sit-for 0.1) ;; ugly hack; but i don't care enough to fix it
+ (call-interactively 'run-geiser)
+ (sit-for 0.2) ;; ditto
+ (end-of-buffer)
+ (pop-to-buffer b)))
+
;;; Geiser mode: