geiser and chez talk to each other https://jao.io/cgit/geiser-chez/atom?h=0.8.1 2015-09-10T02:22:10Z 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! 2011-08-24T01:35:02Z Jose Antonio Ortega Ruiz jao@gnu.org 2011-08-24T01:35:02Z urn:sha1:d708438236cac2ee3c0a63f06eded5d9a6f38a9f Actually, i'm not even sure the calls to format i was using were correct at all! 2011-02-25T15:05:11Z Jose Antonio Ortega Ruiz jao@gnu.org 2011-02-25T15:05:11Z urn:sha1:3f65b0938779e9bd045328cb90d7080b6455652e 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:c676e46833fc2b38b2c21b44b7e6b52b5167329b