[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)


"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.  :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]