GNU bug report logs - #72705
31.0.50; eglot--dumb-tryc Filters out too much

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 72705 <at> debbugs.gnu.org
Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much
Date: Sun, 25 Aug 2024 10:53:10 +0100

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> On 23/08/2024 13:23, João Távora wrote:
>
> I see what you're saying, but insofar that current completion is
> mostly working out well, adding the special logic for parens would
> improve a lot of cases, and keep others the same degree of broken (the
> email-sending ones, for sure). So it might be worth a try.

No, it's not.  It's the kind of complexity Eglot isn't after.  It's a
losing game with the growing number of servers who aren't bound by these
rules in any way.

> Anyway, stopping any partial completion (at first I didn't understand
> that you meant a more general notion that the partial-completion
> c-style) should be similarly easy to what the current patch does. You
> would just drop the second clause in eglot--dumb-tryc, I think. Or
> maybe both the first and the second.

If it's easy, then we should definitely do it.

>> The other "fix" is to lobby with the LSP spec people, but they're very
>> VSCode-inclined.  From what I've seen, even other editors which are more
>> popular than Emacs have very little sway there.
>
> It seems we only have our hacks to help. They got pretty advanced,
> though.

Yes, but they always lose.

>>> Yeah, it'd be great to have C-M-i stop before the paren.
>> No, it wouldn't.  It'd fix this particular case, but it could break
>> in
>> some other future version of LSP where the LSP label isn't a prefix of
>> the thing that selecting that label would insert.
>
> Quite possibly, yes. Though reverting to the simpler behavior at that
> point would just require a 3-4 lines diff, as discussed.

That's more complexity.  And you can't easily know _if_ the LSP label is
or isn't a prefix of the thing selecting the completion would insert
without effectively simulating the completion (which is frequently).

> Alas, this check does not succeed:
>
>   (should (get-buffer-window "*Completions"))

Window management code, likely.

> This works:
>
>   (when (buffer-live-p "*Completions*")
>     (kill-buffer "*Completions*"))
>   (completion-at-point)
>   (should (looking-back "foo"))
>   (should (looking-at "123"))
>   (should (get-buffer "*Completions*"))
>
> Is that better?

It's half-decent, I think.  Please use that.

>>> Okay, I am seeing a difference too: C-M-i does eat the suffix in the
>>> Rust example (the "1234"). But completion with Company does not :-/
>> I can't even get Company to appear in those situations.
> You might have an older version installed?

Maybe.

> 1) Completions are not filtered by suffix, ever.
> 2) Completing count_ones() does not delete the suffix ("1234"
> remains).

Interesting, I thought deleting the 1234 was part of the edit, but the
user of that bug report was after some Emacs specific behaviour.
Anyway, I don't think the test is too brittle, and I think I'd like to
know anyway if something about that breaks anyway.  Maybe you can just
add a comment saying ";; this test might be a bit too brittle, but
interesting nonetheless".

I think you can commit the patch then.  Thanks.
João

Previous Next

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