Hi! "Jose A. Ortega Ruiz" <[email protected]> skribis:
> On Wed, Jan 11 2012, Ludovic Courtès wrote: >> "Jose A. Ortega Ruiz" <[email protected]> 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. Indeed, turning it off in the REPL improves the situation. [...] >> 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. Well, you’re our elisp expert, so I’ll rely on your judgment. :-) Thanks, Ludo’.
