From: "João Távora" <joaotavora@gmail.com>
To: Spencer Baugh <sbaugh@janestreet.com>, emacs-devel <emacs-devel@gnu.org>
Subject: Re: Eglot cannot work with default completion-in-region?
Date: Sat, 27 Jan 2024 14:45:10 +0000 [thread overview]
Message-ID: <CALDnm51OBKCMHoQDsKdGAnoyYb5iYmJbdsqSeBDyc-s8fmwJxw@mail.gmail.com> (raw)
In-Reply-To: <iero7d7hltm.fsf@janestreet.com>
On Fri, Jan 26, 2024 at 8:38 PM Spencer Baugh <sbaugh@janestreet.com> wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.devel as well.
I suppose this email will appear in emacs-devel soon, might
as well start answering.
> The recent commit d376462c7183752bf44b9bd20bf5020fe7eaf75a prompted by
> issue https://github.com/joaotavora/eglot/issues/1339 says:
>
> >I declare it impossible to make C-M-i use of 'try-completion' behave
> >sanely with LSP in its current state. YMMV. Use a completion tooltip,
> >like Company.
>
> So completion from Eglot, which is built into Emacs, is broken out of
> the box?
No.
> It has a hard dependency on using company-mode or similar
> third-party packages?
No.
> If this is the case, perhaps Eglot should make it more clear that it
> cannot be used without also installing and using company-mode or some
> other package. Perhaps it should abort rather than running if the user
> is using the default completion-in-region.
This would be nonsense, given the minute dimension of the problem.
> Alternatively, as someone who uses default completion-in-region and
> would like to use Eglot, is there some way to make the common case
> behave correctly?
_Your_ common case is not other's. I'd just use it and take note where
it breaks down. AFAIK it's _partial_ completion doesn't work as you
would expect from simpler completion models that only serve
strings. A structured survey of cases using a variety of LSPs
would be welcome, if you're inclined to contribute this work.
I just fixed a small minor bug in eglot--dumb-tryc, by
the way, so make sure you grab latest Eglot.
> I guess the issue is that in the LSP protocol, there's a difference
> between the "sortText" and "filterText" which are used for displaying
> completions and letting the user choose them, and the
> "insertText"/"textEdit" which are used for inserting them.
Not the only reason, but that's one of them, yes.
> So Eglot has this somewhat hacky code which runs in :exit-function to
> delete the completion after completion-in-region inserts it, and insert
> a different string instead:
>
> (cond (textEdit
> ;; Revert buffer back to state when the edit
> ;; was obtained from server. If a `proxy'
> ;; "bar" was obtained from a buffer with
> ;; "foo.b", the LSP edit applies to that
> ;; state, _not_ the current "foo.bar".
> (delete-region orig-pos (point))
> (insert (substring bounds-string (- orig-pos (car bounds))))
> (eglot--dbind ((TextEdit) range newText) textEdit
> (pcase-let ((`(,beg . ,end)
> (eglot-range-region range)))
> (delete-region beg end)
> (goto-char beg)
> (funcall (or snippet-fn #'insert) newText))))
> (snippet-fn
> ;; A snippet should be inserted, but using plain
> ;; `insertText'. This requires us to delete the
> ;; whole completion, since `insertText' is the full
> ;; completion's text.
> (delete-region (- (point) (length proxy)) (point))
> (funcall snippet-fn (or insertText label))))
>
> This is code which is often broken, especially with default
> completion-in-region.
If you know of broken cases, contact bug-gnu-emacs@gnu.org and
provide a full reproducible error recipe according to Eglot's
manual (clangd, pyright, or rust-analyzer, gopls preferred,
other servers must come with installation instructions. If
installation too complex/bloaty it may take a while.)
> However, the common case is that sortText==insertText/textEdit.
Is it? The above all return textEdits, I think. How can sortText,
a JSON string, equal textEdit, a JSON object?
> In that case, this code is not necessary, and Eglot doesn't need an
> :exit-function at all.
Indeed. But how do you plan to know this in advance?
> Can Eglot detect this and avoid this somewhat hacky code in that case?
Not easily or cleanly...
> It should be a performance improvement and simplification anyway for all
> completion frameworks.
.. but you can try your hand at a patch. I'd love to be proven wrong.
> (BTW, besides the issue with default completion-in-region, I also ran
> into this while trying to write an OCaml-specific wrapper for
> eglot-completion-at-point function which adds some additional
> completions to those returned from the LSP. But if those completions
> are chosen, then the Eglot exit-function breaks when it tries to look up
> the insertText/textEdit. My LSP doesn't use textEdit at all, though, so
> this is another unnecessary breakage)
What contract exactly is eglot-completion-at-point breaking?
João
next prev parent reply other threads:[~2024-01-27 14:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 20:38 Eglot cannot work with default completion-in-region? Spencer Baugh
2024-01-27 14:45 ` João Távora [this message]
2024-01-27 15:37 ` sbaugh
2024-01-28 10:23 ` Daniel Mendler via Emacs development discussions.
2024-01-28 14:09 ` João Távora
2024-01-29 21:14 ` Spencer Baugh
2024-01-29 22:21 ` João Távora
2024-01-29 22:51 ` JD Smith
2024-01-30 0:32 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALDnm51OBKCMHoQDsKdGAnoyYb5iYmJbdsqSeBDyc-s8fmwJxw@mail.gmail.com \
--to=joaotavora@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=sbaugh@janestreet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.