Suppress eldoc when the current sexp seems to be too large

[rfkm]

This PR restricts the range of searching the beginning of the current sexps for eldoc.

Current version of eldoc could be slow in a large buffer because cider-eldoc-beginning-of-sexp could traverse the whole buffer.
Such a situation is especially prone to happen in the REPL buffer.

In the following example, if the cursor is located at the right of the prompt,
cider-eldoc-beginning-of-sexp calls (forward-sexp -1) about 15 times (user> -> line -> a -> is -> ...).

This is a line
This is a line
This is a line
user>

When the REPL buffer has 4k lines and 35k sexp-like objects (this means (forward-sexp -1) will be called 35k times),
cider-eldoc-beginning-of-sexp takes about 4 seconds in my environment.
With my fix, it takes less than 0.001 seconds.

This might be related to #1361.

[bbatsov]

There should probably be comments here explaining why this is necessary (for posterity's sake).

[bbatsov]

This seems like a good solution for now, although long-term it seems to me that we should improve the process of sexp boundaries detection in the REPL.

[rfkm]

Updated.

Yeah, I had been going to do so with narrowing at first, but I found it difficult to detect the boundary strictly because we might sometimes want eldoc to work with sexp in a log message in a REPL buffer.

[bbatsov]

because we might sometimes want eldoc to work with sexp in a log message in a REPL buffer.

I don't know - it seems to me that if something isn't REPL input we can safely ignore it in terms of eldoc.

[cap10morgan]

Do we need to add something to the changelog for this? Never mind, should have looked at the changes first. I was expecting to see something in Bug Fixes, but this is perf, so makes sense. I'll get it into the v0.10 PR.

[Malabarba]

I think the proper way to do this would be to narrow from input-start to end-of-buffer, and then find the start of current sexp by running syntax-ppss. If point is before input-start then just don't do eldoc (or maybe do it by narrowing from beginning of line).

This might still be slow if the user pastes some huge sexp into the REPL (unlikely) but we can get around that by checking the size of the narrowed buffer.

[Malabarba]

But, in any case, thanks for looking into this. :-)