diff options
author | Jose Antonio Ortega Ruiz <jao@gnu.org> | 2015-09-10 04:22:10 +0200 |
---|---|---|
committer | Jose Antonio Ortega Ruiz <jao@gnu.org> | 2015-09-10 04:22:10 +0200 |
commit | 0db9d5c26a82ee5f318655719ceb7d4bea8f74a7 (patch) | |
tree | d87a5b3de8e9d2749f6b949cad8c008d2946af9f /elisp/geiser-version.el.in | |
parent | 4c9dddb1a668a7a5cbac217c45558ad5e419cc9d (diff) | |
download | geiser-0db9d5c26a82ee5f318655719ceb7d4bea8f74a7.tar.gz geiser-0db9d5c26a82ee5f318655719ceb7d4bea8f74a7.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 'elisp/geiser-version.el.in')
0 files changed, 0 insertions, 0 deletions