geiser/elisp, branch masteremacs and scheme talk to each otherhttps://jao.io/cgit/geiser/atom?h=master2026-07-18T00:08:24Zinlining2026-07-18T00:08:24Zjaojao@gnu.org2026-07-18T00:08:24Zurn:sha1:3e506d06b34ccda8a50ac3e43c90d722c00065fea better refactoring2026-07-18T00:06:41Zjaojao@gnu.org2026-07-18T00:06:41Zurn:sha1:e9743982bac463c992440787e2c9e0b187f38892wee refactoring2026-07-17T23:45:34Zjaojao@gnu.org2026-07-17T23:45:34Zurn:sha1:a362ba4ab844e696d0c65fb012ce155457b38ecbfix(repl): prevent wrong-type-argument stringp nil2026-07-15T22:06:58Zterryterry.cadd@gmail.com2026-07-15T22:06:58Zurn:sha1:727347e968fe2e05ffd33992792acf036edef1cd
using chicken scheme 5.4.0 and geiser i was getting this
message repeatedly after every expression entered in repl
geiser-repl--output-filter: Wrong type argument: stringp, nil
in my case (geiser-con--connection-debug-prompt geiser-repl--connection)
evaluated to nil causing string-match-p to error out
(defun geiser-repl--matches-prompt-p (txt) ...
txt was found to be the empty string most times ""
essential reduces to (string-match-p nil "")
so put some conditional pieces for txt is not a string,
if string is empty , no point checking since not a prompt
just use conjunction and to prevent string-match-p on nil on both
prompts
and use disjunction or to get next prompt type if first failed to match
thnaks
version bump2026-05-23T15:02:14Zjaojao@gnu.org2026-05-23T15:02:14Zurn:sha1:84c25e9683a18d00387b6c16b0cee66269536c3centering debug mode should also unfreeze the repl2026-05-09T22:18:46Zjaojao@gnu.org2026-05-09T22:18:46Zurn:sha1:6071202dfec784d53e5e9a6946e9ee06be8e34c6
this should fix issue #105
make sure no input is sent to non-active connections2026-05-04T16:59:26Zjaojao@gnu.org2026-05-04T16:59:26Zurn:sha1:06c3db4a053331e3d1fb8642a49c7a9b810cf5cb
and, while we're at it, remember to re-activate them when the repl has
returned a prompt.
this should address issue #79
version 0.332026-05-02T23:08:05Zjaojao@gnu.org2026-05-02T23:08:05Zurn:sha1:55b4b7847902d626a76e110a862d0fde1d1ff297new attempt at fixing #742026-04-26T18:50:45Zjaojao@gnu.org2026-04-26T18:50:45Zurn:sha1:185191df527b51ce521084f8c32030e87dabb5e9
It all seems to boil down to ansi-color-filter not recognising the format used
by guile-colorized, and leaving behind some control characters that we're
cleaning manually after the fact.
This is not a great solution, as it applies a guile bandage to all
implementations: we should define an implementation-dependent filter for input
coming from a remote repl, but the fact that it has also to be applied to
connections complicates matters.
Revert "cleaning ansi colours also in the repl (#74)"2026-04-26T17:26:44Zjaojao@gnu.org2026-04-26T17:26:44Zurn:sha1:df9a3d3d8ae10417294c076d5804643441a1efca
This reverts commit 2e9d5e04e7ddf2727555c74c468bd009ecbdbd92.
The problems with guile-colorized in remote repls go deeper than simply
removing ansi-color codes. Moreover, ansi-color-filter doesn't recognize the
control commands it generates. But even when removing them by hand, initial
requests for evaluating get no response.