Re: [Geiser-users] Graceful handling of long lines in the REPL

[Jose A. Ortega Ruiz]

On Wed, Jan 11 2012, Ludovic Courtès wrote:

> Hi Jao!
>
> "Jose A. Ortega Ruiz" <address@hidden> 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