GNU bug report logs - #68072
pp functions have O(n^2) runtime with lisp-indent-function set to common-lisp-indent-function

Previous Next

Full log

View this message in rfc822 format

From: Brennan Vincent <brennan <at> umanwizard.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 68072 <at> debbugs.gnu.org
Subject: bug#68072: pp functions have O(n^2) runtime with lisp-indent-function set to common-lisp-indent-function
Date: Thu, 28 Dec 2023 10:37:09 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I can definitely agree: `pp` using the default `pp-default-function`
> (i.e. `pp-fill`) is *not* a good idea if you have changed
> `lisp-indent-function` (unless you changed it to a faster function, of
> course).  We may be able to fix this O(N²) behavior, but the underlying
> principle stands: it's much too easy to fall into another O(N²) behavior.
>

Thanks for the tip and I can definitely remove the customization of
lisp-indent-function to common-lisp-indent-function. I actually don't
remember why I originally set it since I don't write common lisp... but
anyway, if we don't expect changing lisp-indent-function globally to
behave nicely with other features (like pp), perhaps
lisp-indent-function shouldn't be Customize-able , or we should at least
mention this in the documentation?

>> This also causes eglot (in its default configuration) to hang when
>> opening large Rust files, since rust-analyzer tends to send large amounts of
>> inlay hints, and eglot logs the messages it receives as pretty-printed
>> Lisp objects.
>
> And Eglot should probably use a faster pretty printer than the default
> `pp` for that.  Maybe we should make `lisp-data-mode` set
> `pp-default-function` or `lisp-indent-function` to avoid such problems?
>
>
>         Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.