geiser/elisp, branch 0.1 emacs and scheme talk to each other https://jao.io/cgit/geiser/atom?h=0.1 2010-12-18T15:02:46Z Missing autoload for connect-to-racket 2010-12-18T15:02:46Z Jose Antonio Ortega Ruiz jao@gnu.org 2010-12-18T15:02:46Z urn:sha1:6d92998062b665794eb1db1f08e595de6707779f 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 bit 2010-12-15T18:18:04Z Jose Antonio Ortega Ruiz jao@gnu.org 2010-12-15T18:18:04Z urn:sha1:7c1723140c19e0332aabaad42b314a154e391da7 If quack-mode is active, we leave additional font locking to it. Debugging aids 2010-12-14T22:21:23Z Jose Antonio Ortega Ruiz jao@gnu.org 2010-12-14T22:21:23Z urn:sha1:753b2b8d34480ae39ce803b28aecb52d7c5ff99c 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 errors 2010-12-14T21:57:18Z Jose Antonio Ortega Ruiz jao@gnu.org 2010-12-14T21:57:18Z urn:sha1:759da77c957816820803d525ed8779224a89aec3 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 customizable 2010-12-11T02:03:00Z Jose Antonio Ortega Ruiz jao@gnu.org 2010-12-11T02:03:00Z urn:sha1:e14bbe5c8c18bcc0f202a4362ff573e6c02034d9 This is Emacs, after all. Print long expressions after errors in debug buffer. 2010-12-11T01:47:56Z Jose Antonio Ortega Ruiz jao@gnu.org 2010-12-11T01:47:56Z urn:sha1:08e2e3fbda3092dea615d024e408d400ae8b2493 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*-values 2010-11-30T21:54:43Z Jose Antonio Ortega Ruiz jao@gnu.org 2010-11-29T01:06:46Z urn:sha1:1b5df354277077309a67967f7347deb8c6dce64e ... and i haven't yet refactored `geiser-syntax--scan-locals', oh my. Fixes for locals scanning 2010-11-29T00:42:37Z Jose Antonio Ortega Ruiz jao@gnu.org 2010-11-29T00:42:37Z urn:sha1:d4676101dbce785b8b4783dcbdf20bd73a0e9a20 ... 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 fixed 2010-11-28T15:09:03Z Jose Antonio Ortega Ruiz jao@gnu.org 2010-11-28T15:09:03Z urn:sha1:7cc98abc1d8ad68e350a176fb0d1ddbe7796fad1 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 internalisation 2010-11-28T15:07:42Z Jose Antonio Ortega Ruiz jao@gnu.org 2010-11-28T15:07:42Z urn:sha1:707d0afb8c443f1c6e624d6d432b21ca44636937 We were still internalizing scheme _keywords_ in the elisp reader.