geiser and guile talk to each other https://jao.io/cgit/geiser-guile/atom?h=0.28.4 2020-07-20T03:41:00Z 2020-07-20T03:41:00Z jao jao@gnu.org 2020-07-20T03:41:00Z urn:sha1:aab5226dfe937861c54729744e8add15d931f758 2015-12-14T03:22:48Z Jose Antonio Ortega Ruiz jao@gnu.org 2015-12-14T03:22:48Z urn:sha1:a1078b906f73bfe69754390908083ae8fab48b3f 2015-12-14T02:49:33Z Jose Antonio Ortega Ruiz jao@gnu.org 2015-12-13T22:15:48Z urn:sha1:afa28c8a82f81a66eda3b12c2f7279e5c3a25368 Using cond-expand to provide support for the new world of guile 2.2 2015-09-10T02:22:10Z Jose Antonio Ortega Ruiz jao@gnu.org 2015-09-10T02:22:10Z urn:sha1:58484400fd3dde3ec28057159ce55f22fcb6c919 Soooo, the long delay experienced when evaluating long string lists in Guile had nothing to do with the time took by emacs to read the response from the scheme process; that process is always a breeze, no matter or its format or number of newlines. The delay was provoked by an innocent looking function that scans the received string (which includes a prompt at the end as an EOT marker) to check whether Guile (or any other scheme) has just entered the debugger (that's done inside `geiser-con--connection-update-debugging`). For some reason, `string-match` on that kind of string using Guile's regexp for a debug prompt takes forever. Instead of trying to optimize the regular expression, i've just applied it to the *second* line of the received string, which is the one that contains the response's prompt. 2015-09-08T21:51:21Z Jose Antonio Ortega Ruiz jao@gnu.org 2015-09-08T21:51:21Z urn:sha1:2f91e2e4efc776a3b8808c534491edaea6642f93 Should fix issue #85 2015-09-03T02:21:50Z Jose Antonio Ortega Ruiz jao@gnu.org 2015-09-03T02:21:50Z urn:sha1:85bf381f6a2bdf475eaf469fa2841c0422ed5605 We use the same trick as chicken for guile, and pretty-print the evaluation results before writing them. The trick wasn't working at all until i specified a value for the undocumented keyword parameter `#:max-expr-width`, which makes me think i might be missing something. 2013-09-13T18:36:56Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-09-13T18:36:56Z urn:sha1:9d0d38a20850f3f9eecd74267970748bbcbc6bdc We add the paths in geiser-guile-load-path also to %load-compiled-path, and new directories added to the load path via geiser-add-to-load-path are added to both %load-path and %load-compiled-path. Here's hope Ludovic will like all these additions! 2011-09-11T19:35:15Z Jose Antonio Ortega Ruiz jao@gnu.org 2011-09-11T19:35:15Z urn:sha1:4c022191fac48d9f5d96cfafeda6aba59da627de We were just ignoring it so far! 2011-02-25T15:05:11Z Jose Antonio Ortega Ruiz jao@gnu.org 2011-02-25T15:05:11Z urn:sha1:420a8c4d96ff19786e4a16a34fcd6b5a98da500b This is a 2.0 fluid that governs how warning messages are displayed. In Geiser, we need the prefix set to an empty string so that file paths are clickable (and the display in a separate emacs buffer is nicer). 2011-02-09T13:21:24Z Jose Antonio Ortega Ruiz jao@gnu.org 2011-02-09T13:21:24Z urn:sha1:67e9ff26c6cac413572034ffbd69ba9212085014