geiser-guile/geiser, branch 0.12geiser and guile talk to each otherhttps://jao.io/cgit/geiser-guile/atom?h=0.122020-05-10T18:13:43ZMake guile return line numbers more often, as suggested by Sergey2020-05-10T18:13:43ZJose Antonio Ortega Ruizjao@gnu.org2020-05-10T18:13:43Zurn:sha1:20043b13bb9756079d73c68ffd3942cecedb2b9e
See gitlab issue #303, where Sergey Trofimov kindly described not only
the symptons, but this cure.
guile 2.2: program-arities and program-module reloaded2018-01-30T22:45:41ZJose Antonio Ortega Ruizjao@gnu.org2018-01-30T22:45:41Zurn:sha1:e975e10772f8c0595dfed21f1ac2ad783deeb9f2
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.
Fixing guile 2.2 compatibility2015-12-14T03:22:48ZJose Antonio Ortega Ruizjao@gnu.org2015-12-14T03:22:48Zurn:sha1:a1078b906f73bfe69754390908083ae8fab48b3fSupport for guile-2.22015-12-14T02:49:33ZJose Antonio Ortega Ruizjao@gnu.org2015-12-13T22:15:48Zurn:sha1:afa28c8a82f81a66eda3b12c2f7279e5c3a25368
Using cond-expand to provide support for the new world of guile 2.2
Speeding up debugger check (addresses #64)2015-09-10T02:22:10ZJose Antonio Ortega Ruizjao@gnu.org2015-09-10T02:22:10Zurn: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.
Ensuring switch-to-geiser asks for an implementation2015-09-08T21:51:21ZJose Antonio Ortega Ruizjao@gnu.org2015-09-08T21:51:21Zurn:sha1:2f91e2e4efc776a3b8808c534491edaea6642f93
Should fix issue #85
guile: pretty printing evaluation results (#64)2015-09-03T02:21:50ZJose Antonio Ortega Ruizjao@gnu.org2015-09-03T02:21:50Zurn: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.
Guile: augmenting %load-compiled-path too2013-09-13T18:36:56ZJose Antonio Ortega Ruizjao@gnu.org2013-09-13T18:36:56Zurn: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!
Guile: Fix subr argument name retrieval for Guile >= 2.0.9.2013-06-04T12:50:22ZLudovic Courtèsludo@gnu.org2013-06-04T12:42:57Zurn:sha1:6c9efbc61592aa24429d5c29b641b7f1ff1eff51Finishing removal of the "foo ends here" footers2012-10-11T02:20:23ZJose Antonio Ortega Ruizjao@gnu.org2012-10-11T02:19:50Zurn:sha1:8624afc1961d468542cb4090c99187dc2745542f
I must admit this is yet another excuse to check geiserbot over at
freenode.