[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Geiser-users] Graceful handling of long lines in the REPL
From: |
Ludovic Courtès |
Subject: |
Re: [Geiser-users] Graceful handling of long lines in the REPL |
Date: |
Thu, 12 Jan 2012 22:54:42 +0100 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) |
Hi!
"Jose A. Ortega Ruiz" <address@hidden> skribis:
> On Wed, Jan 11 2012, Ludovic Courtès wrote:
>> "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.
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’.