On Wed, Jan 11 2012, Ludovic Courtès wrote: > Hi Jao! > > "Jose A. Ortega Ruiz" <j...@gnu.org> skribis: > >> Unfortunately, geiser does not provide an elisp sexp shortener (it uses >> the scheme services for the shortened value that you see in the echo >> area after evaluation, and does not interfere with evaluations performed >> at the REPL), so you'd need to hack you own. > > Actually, I think the problem is that Emacs has a hard time dealing with > long lines in general, and the REPL just makes it easier to trigger the > problem. Namely, it appears to spend time in string_match_1 and > re_search, which presumably take time proportional to the line length.
This must be font-lock's fault. A possible alternative would be to deactivate, somehow, font-lock in the buffer when the string is too long, but i don't think that can be done on a per-region basis... well, not easily: one can define a new font-lock function and make it do whatever's convenient, of course. > So rather than shortening sexps, I think inserting newlines, say, > between datums, would solve the problem (something that can be done in > a pre-output filter function, I suppose.) If you don't care much about splitting atoms in the middle, this is an easy workaround as a pre-output filter function, yes... provided the problem are long lines (perhaps font-lock is that slow only for long lines (as opposed to long expressions)... you can easily check by disabling font locking in the REPL and see what happens). A better possibility here could be `pp' and friends (from pp.el), the elisp pretty-printer: it may get confused at corner cases where scheme syntax differs from elisp's, but perhaps it is good enough. jao -- You don’t stop doing things because you get old. You get old because you stop doing things. - Rosamunde Pilcher
