geiser-guile/elisp, branch 0.1geiser and guile talk to each otherhttps://jao.io/cgit/geiser-guile/atom?h=0.12010-12-18T15:02:46ZMissing autoload for connect-to-racket2010-12-18T15:02:46ZJose Antonio Ortega Ruizjao@gnu.org2010-12-18T15:02:46Zurn:sha1:ea2af4ac14c3351094377bc06f41232de9a6fb94
Maybe i should bite the bullet and use ##autoload cookies, but then
geiser.el would need to be a generated file, breaking
out-of-the-boxness (unless i update it by hand). Sticking to manual
maintenance for now.
A quack compatibility bit2010-12-15T18:18:04ZJose Antonio Ortega Ruizjao@gnu.org2010-12-15T18:18:04Zurn:sha1:4b7a1b2afe0630e5b4c02f6cbe23bee53aa62eb9
If quack-mode is active, we leave additional font locking to it.
Debugging aids2010-12-14T22:21:23ZJose Antonio Ortega Ruizjao@gnu.org2010-12-14T22:21:23Zurn:sha1:176b84f5aedc1bb23d91337b10570981e9af7545
A couple functions to manage logs, and a fix to the definition of
geiser-messages-mode: do not ever kill all local variables in a
derived mode definition!
No more vicious error circle on tq errors2010-12-14T21:57:18ZJose Antonio Ortega Ruizjao@gnu.org2010-12-14T21:57:18Zurn:sha1:8cac1fd62779f6552ce4e5ac5d8f9a886526420d
I've eliminated the annoying *spurious* popup produced by tq, so that
Geiser can recover from error conditions arising from unexpected
input to a transaction queue that has no active transaction. We now
log the offending input and keep going.
Greg, over at racket's list, reported such a happening when leaving
the REPL after C-u C-c C-z; but i've been unable to reproduce the
problem. Probably, we have a bug lurking somewhere that this patch
doesn't fix, but at least it should work as a palliative.
Make the position of long expressions in debug buffer customizable2010-12-11T02:03:00ZJose Antonio Ortega Ruizjao@gnu.org2010-12-11T02:03:00Zurn:sha1:4a156187b4918e934c30ea2403d8dcb57cfcc720
This is Emacs, after all.
Print long expressions after errors in debug buffer.2010-12-11T01:47:56ZJose Antonio Ortega Ruizjao@gnu.org2010-12-11T01:47:56Zurn:sha1:45dbc624fcb57134c02db510a7f3ba50b09f4d88
You won't believe it, but people write procedures spanning several
pages, even in Scheme. Where's the art and the poetry of programming?
Locals scanning: support for let-values and let*-values2010-11-30T21:54:43ZJose Antonio Ortega Ruizjao@gnu.org2010-11-29T01:06:46Zurn:sha1:21e65eb32c09d8524ec61b12a70a4f7f1379eedf
... and i haven't yet refactored `geiser-syntax--scan-locals', oh my.
Fixes for locals scanning2010-11-29T00:42:37ZJose Antonio Ortega Ruizjao@gnu.org2010-11-29T00:42:37Zurn:sha1:e4f87fdc18d4aef2c4e7c3602ac3975f2140fae1
... using the new non-interning reader. Plus scanning for case-lambda
and syntax-rules. `geiser-syntax--scan-locals' is in danger of
refactoring, specially if we add support for let-values.
Autodoc's argument display fixed2010-11-28T15:09:03ZJose Antonio Ortega Ruizjao@gnu.org2010-11-28T15:09:03Zurn:sha1:d70e9de59cfeae4fa8e76a48dbfe80e9d25e0d7c
It was relying on symbol equality, and not dealing correctly with
keyword arguments in this new external world. In the process, some
cleanups to the scheme data display code.
Avoiding keyword internalisation2010-11-28T15:07:42ZJose Antonio Ortega Ruizjao@gnu.org2010-11-28T15:07:42Zurn:sha1:e61a8e7c9068fab436b657ed42c1df2f73a8b6f3
We were still internalizing scheme _keywords_ in the elisp reader.