summaryrefslogtreecommitdiff
path: root/doc/img/guile-eval-error.png
diff options
context:
space:
mode:
authorJose Antonio Ortega Ruiz <jao@gnu.org>2015-09-10 04:22:10 +0200
committerJose Antonio Ortega Ruiz <jao@gnu.org>2015-09-10 04:22:10 +0200
commitdb8ab30c7587616edd99cb90bfdfa77fe4e702ac (patch)
tree9565261d5cd73da56699b863cafd83cc29667703 /doc/img/guile-eval-error.png
parent4f31a25509f5d4a93559a3feb751cdfbef0464b5 (diff)
downloadgeiser-guile-db8ab30c7587616edd99cb90bfdfa77fe4e702ac.tar.gz
geiser-guile-db8ab30c7587616edd99cb90bfdfa77fe4e702ac.tar.bz2
Speeding up debugger check (addresses #64)
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.
Diffstat (limited to 'doc/img/guile-eval-error.png')
0 files changed, 0 insertions, 0 deletions