Reading

Geiser

I hope you’ll pardon a shameless plug of one of my latest hacks, Geiser, a new Emacs-Scheme interaction mode.

After having lots of fun implementing Fuel, i was left with a lot of Elisp code that, i realized, could be easily reused for languages other than Factor. I also decided that it was high time to stop whining about Scheme environments not being dynamic enough and do something about it. As they say, talk is cheap.

Thusly, Geiser was born, and today it came of 0.0.1 0.0.2 age, as per the git tag in its repository.

If you know Slime or Fuel, you know what Geiser aims at: a pleasant, live interaction with Scheme without leaving Emacs. This first release is by no means there yet, but you’ll already find some joy using it: module-aware and incremental evaluation, jumping to definitions, dynamic symbol completion and automatic signature display in the echo area are the highlights.

Currently, Geiser supports two Scheme implementations: Guile and PLT. Yeah, i like both (and several others). It’s been really fun discovering how to tweak them to obtain the metadata i wanted, and their developers and users have been helpful, kind and patient to no end. A big thanks to them (you know who you are), and my promise that i’ll keep nagging.

Both Guile and PLT have given me many pleasant surprises. Guile is the most common-lispy Scheme around, and the recent hard work and improvements by the likes of Andy Wingo is making much of the criticism it memetically receives just moot. And PLT is by no means the rigid system i thought it was, while retaining all the great features i knew it had. Try any of them, with or without Geiser: they’re real fun.

Back to Geiser, this being an alpha release, there’s no screencasts or real documentation… the code just escaped leaving a blood trail, you know. Maybe one day it’ll have a webpage, a mailing list and even users. In the meantime, if you’re brave enough, the README will hopefully do; and, of course, the code:

git clone git://gitorious.org/geiser/mainline.git

(If you’re not brave enough, but curious, the code is browsable here.)

Needless to say, all kinds of comments, criticisms and laundry lists are welcome and, actually, encouraged.

Just in case someone else encounters Ryszard’s problem: Geiser requires PLT Scheme 4.1.5.5 or better, which, as of this writing, means that one needs to get the SVN version. There also seem to be some problems with versions of Emacs prior to 22.3.

Someone more familiar with Chicken please correct me if i’m wrong, but last time i checked i found csi not good enough at providing metadata. I’m not sure if the recent 4.x releases brought significant improvements, though.

Each supported scheme implementation consists of two parts: an elisp layer, and a scheme backend. The former is easy (see for instance geiser-guile.el or geiser-plt.el), being basically a translation of elisp calls to scheme ones, which are implemented for each supported implementation in scheme (for instance, scheme/guile/geiser/emacs.scm is the exported interface for guile). Geiser relies almost exclusively on the scheme implementation to obtain the metadata it displays (there’s very little scheme semantics on the elisp side), and that, unfortunately, means that support for chicken won’t be as good as for the PLT or Guile (at least that’s my impression after skimming Chicken’s documentation): basically, you want a scheme implementation as close as possible to CL when it comes to reflection and run-time information. That said, there’s provision for gracefully support a subset of the functionality. There were a couple of people in #scheme that seemed interested in a Chicken backend some weeks ago: perhaps you could ask there.

worked immeadately on Debian Lenny and emacs22-nox. i’m guile user, so i just put in ‘guile as described in the README. i’m usually using cmuscheme by Olin Shivers but this seems like a posssible alternative… regards b.

[...] Here is the announcement for a new Emacs-Scheme interaction mode that already works with PLT and Guile, and will probably soon be working with Ikarus, too. This was written by Grant. Posted on Saturday, May 30, 2009, at 9:24 pm. Filed under Link. Tagged Emacs, Ide, Programming Language, Scheme. Bookmark the permalink. Follow comments here with the RSS feed. Post a comment or leave a trackback. [...]

Having a bit of trouble getting it going on OS X with PLT Scheme v4.2.3, Emacs v23.1.1. It gives me the same “No Geiser REPL for this buffer” error others were getting. It also had geiser-scheme-dir wrong, so I set it to /usr/local/share/geiser, to no avail. Any ideas?

Alex, does this happen with an installed geiser (did you run make install)? If so, what’s your .emacs configuration? What is the value of geiser-scheme-dir before you set it? What exactly happens when you run M-x run-plt? Do you get a REPL buffer?

This is what led me to figuring out that geiser-scheme-dir was incorrect; I changed it to where geiser installed to (/usr/local/share/geiser) and that error goes away, but geiser still doesn’t seem to detect the REPL. I’m assuming M-x run-plt is the same as M-x run-geiser, but with PLT specified?

The long pause leading to the “cannot open input file” is indeed solved. The errors I get now are when I try to run the buffer in the repl (C-c C-l), run the preceding sexp, etc – autodoc also says “Autodoc not available (No Geiser REPL for this buffer (try M-x run-geiser))”, despite a REPL being opened; everything makes the same complaint.

geiser-plt-binary was set to “mzscheme”. Just to be sure, I set it to an absolute path to mzscheme, but that hasn’t changed anything. The REPL works fine, the geiser buffers just don’t seem to be aware of it.

Ah hah! That was it. My file extension was .scm, not .ss. I saved it as .ss and re-opened. Now the modeline is “(Scheme Plt/A)”, and everything seems to work properly (Autodoc, C-c C-l, and C-x C-e tested). Thank you very much for your help.

In the REPL (using mzscheme), if I start defining a function, and then press enter to go to the next line, to continue the definition, is there any way to set up tab to indent properly. Pressing tab in this circumstance freezes my emacs. Calling the function indent-for-tab-command indents to the last line’s opening paren. The indent-line-function is indent-relative. Calling lisp-indent-line does not move the point. Please let me know if you know of any adjustments I could make to my .emacs so that this works similarly to SLIME or quack. Thanks.

that’s because TAB is trying to complete the symbol at point (and there’s none). I’ll see to fix this bad behaviour, and adding indentation capabilities a la slime to Geiser’s REPL. Thanks for the report and patience! :)

First of all, thank you for the good work.
The only thing I cannot do is to eval/load/compile code from my buffers in the REPL, so the definitions are then available in the REPL.
The key combinations that appear in the README file such as C-M-x don’t work. If I press M-x geiser-compile-current-buffer it seems to compile the file, but once it’s done, the definitions aren’t available in the REPL.
I’m using geiser’s last version from git with PLT Scheme (version 4.2.5). I’m using ArchLinux.
Do you know what the problem could be?
The only thing I found to work around this problem is to write (require “file.scm”) in the REPL, but would like to have a faster way to do it and be able to eval just one sexp from the buffer.

rata, the expressions are evaluated in the namespace of the file’s module, so you won’t see them in the REPL unless you switch to that module’s namespace. You can do that in the repl using (enter! (file “path/to/file.scm”)) or, more conveniently, by pressing C-uC-cz in the scheme buffer (that’s “go to the repl and switch to current module”). You’ll notice that you’re in the proper namespace because the prompt will change to reflect that.
To return to the top-level, use (enter! #f).

If that doesn’t work, pressing things like C-M-x should give you some kind of error: is that the case?