headers
Ludovic Courtès | 11 Jan 2012 18:43
Picon

Graceful handling of long lines in the REPL

Hello Geiserati!

One problem I regularly stumble upon is that if you inadvertently write
a large data structure in the REPL (say, (iota 10000000)), Emacs has a
hard time displaying it and gets slower and slower, to the point where
hitting C-c C-c in the REPL buffer has no effect other than displaying
“C-c” after some delay.

The workaround is to kill the REPL buffer (and associated process)
before Emacs becomes completely unusable–which is inconvenient.

Any ideas how to fix that?

Thanks,
Ludo’.
Permalink | Reply |
headers
Jose A. Ortega Ruiz | 11 Jan 2012 19:26
Picon
Gravatar

Re: Graceful handling of long lines in the REPL


Heya Ludovic,

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

> Hello Geiserati!
>
> One problem I regularly stumble upon is that if you inadvertently write
> a large data structure in the REPL (say, (iota 10000000)), Emacs has a
> hard time displaying it and gets slower and slower, to the point where
> hitting C-c C-c in the REPL buffer has no effect other than displaying
> “C-c” after some delay.
>
> The workaround is to kill the REPL buffer (and associated process)
> before Emacs becomes completely unusable–which is inconvenient.
>
> Any ideas how to fix that?

There's a hook called by comint-mode before displaying its output,
comint-preoutput-filter-functions.  Functions registered there receive
the text to be output and must return a replacement for it.  The text
includes the prompt and comint and geiser use its form for various ends
(e.g., for detecting when the debugged is entered/exited), so you should
make sure that you don't modify that in the returned string.

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.
(Continue reading)

Permalink | Reply |
headers
Ludovic Courtès | 11 Jan 2012 22:18
Picon

Re: Graceful handling of long lines in the REPL

Hi Jao!

"Jose A. Ortega Ruiz" <jao@...> 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.

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

(I tried longlines-mode in the REPL but it makes Emacs unusable even
sooner.)

WDYT?

Thanks,
Ludo’.
Permalink | Reply |
headers
Ludovic Courtès | 11 Jan 2012 22:20
Picon

Re: Graceful handling of long lines in the REPL

Hi Jao!

"Jose A. Ortega Ruiz" <jao@...> 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.

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

(I tried longlines-mode in the REPL but it makes Emacs unusable even
sooner.)

WDYT?

Thanks,
Ludo’.
Permalink | Reply |
headers
Jose A. Ortega Ruiz | 11 Jan 2012 23:07
Picon
Gravatar

Re: Graceful handling of long lines in the REPL

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

> Hi Jao!
>
> "Jose A. Ortega Ruiz" <jao@...> 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
(Continue reading)

Permalink | Reply |
headers
Ludovic Courtès | 12 Jan 2012 22:54
Picon

Re: Graceful handling of long lines in the REPL

Hi!

"Jose A. Ortega Ruiz" <jao@...> skribis:

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

>> "Jose A. Ortega Ruiz" <jao@...> 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
(Continue reading)

Permalink | Reply |

Gmane