geiser and guile talk to each other https://jao.io/cgit/geiser-guile/atom?h=0.11.2 2018-01-30T22:45:41Z 2018-01-30T22:45:41Z Jose Antonio Ortega Ruiz jao@gnu.org 2018-01-30T22:45:41Z urn:sha1:3f2272ecf02c8049ea5f250e6263d0f9441a0bd8 Those two procedures are gone in these 2.2 times, and things like autodoc and xref were broken as a result. With Andy's help, apparently good enough approximations of their functionality are now in place: let's see how they go. 2015-12-14T03:22:48Z Jose Antonio Ortega Ruiz jao@gnu.org 2015-12-14T03:22:48Z urn:sha1:b222e5535ff372441a5b366b19a42555e96f51bd 2015-12-14T02:49:33Z Jose Antonio Ortega Ruiz jao@gnu.org 2015-12-13T22:15:48Z urn:sha1:faa5da7c249ced4434020619e890f44190caef8a 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:db8ab30c7587616edd99cb90bfdfa77fe4e702ac 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:8eb2aafedbb2a65a69a830814da61395cf276c54 Should fix issue #85 2015-09-03T02:21:50Z Jose Antonio Ortega Ruiz jao@gnu.org 2015-09-03T02:21:50Z urn:sha1:bd42523b61ff81dae4bf585fc2fabda4a94d8bd3 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:393305d2fcf612f4e5f99383f680f819b458c326 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! 2013-06-04T12:50:22Z Ludovic Courtès ludo@gnu.org 2013-06-04T12:42:57Z urn:sha1:99e1cb68577896b2d1afcc9b6ab52e5c6a3a523f 2012-10-11T02:20:23Z Jose Antonio Ortega Ruiz jao@gnu.org 2012-10-11T02:19:50Z urn:sha1:b0684896df77372e8be1f4bcf6d6b7a1cb142b47 I must admit this is yet another excuse to check geiserbot over at freenode. 2011-09-11T19:35:15Z Jose Antonio Ortega Ruiz jao@gnu.org 2011-09-11T19:35:15Z urn:sha1:d0b0b31399fe00b877b5dfefc2e3563aa6f257ed We were just ignoring it so far!