Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much

From: João Távora <[email-masked]>
Date: Tue, 20 Aug 2024 10:40:01 +0100

On Tue, Aug 20, 2024 at 3:08 AM Dmitry Gutov <[email-masked]> wrote:

> So far I've tested with gopls and clangd (when writing the new tests),
> typescript-language-server and rust-analyzer.

That's pretty good.  If you could add pylsp or pyright (basedpyright),
I'd feel even more confident.

> All right.
>
> The proposed change doesn't alter the kinds of strings that are
> inserted, only the cases when that happens. When the added predicate
> returns nil, we fall back to the next clause; and the check at the end
> also allows us to return nil, which is useful in certain rare contexts.

I don't have time to spend examining these details, just the final
outcome is relevant: partial completions cannot be inserted, but
fragments of a completion can be completed to a fully formed
completion (eventually running exit-function then).

> The report that's referenced in the 3 commits your mentioned does seem
> to have regressed is https://github.com/joaotavora/eglot/issues/1339
> not to the original behavior (exit-function still works), but C-M-i
> changes buffer text to
>
>    v.call1234.1234567890

I don't have time to investigate right now, but indeed that issue there were
two consecutive fixes: the first one (which you say "still works") and a second
one which I eventually reverted because it fixes some things and broke
others.

So is the regression you mention in relation to the current Eglot state or
to that intermediate state?

Regardless, if possible, make an automated test and mark it "expected
failing" to record this fact.

> I suppose that could be fixed by moving some matching logic from the
> style into the completion table. Not sure how important/realistic the
> example is, although somebody did report it...

I'd have to have a clearer view on what exactly has regressed and what
has advanced.  Then a better decision can be made.  Thank you for
this work.

João