all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Ruijie Yu <ruijie@netyu.xyz>
Cc: 62315@debbugs.gnu.org
Subject: bug#62315: 30.0.50; [BUG] Rust eglot tuple struct field completion
Date: Wed, 22 Mar 2023 10:37:49 +0000	[thread overview]
Message-ID: <878rfpvzpe.fsf@gmail.com> (raw)
In-Reply-To: <sdvjzz9v053.fsf@fw.net.yu> (Ruijie Yu's message of "Wed, 22 Mar 2023 13:11:14 +0800")

Ruijie Yu <ruijie@netyu.xyz> writes:

> CC'ing João because eglot.  Thanks.
>
>> I can't word it, so let me explain via an example.  The Emacs in
>> question was built a few days ago, FTR.
>>
>> Also, note that I am using rust-ts-mode as the major mode, since
>> it is the only builtin rust major mode, with the corresponding grammar
>> lib cloned and built moments ago.
>>
>> $ cd "$(mktemp -d)"
>> $ cargo init --name foo --lib
>> $ emacs -Q src/lib.rs
>>
>> Replace src/lib.rs with the following content, then revert buffer and
>> run `eglot':
>>
>> //  -*- mode: rust-ts; -*-
>> /// 0..=10
>> #[derive(Default)]
>> struct Foo(u32, u32, u32, u32, u32, u32, u32, u32, u32, u32, u32);
>>
>> fn foo(f: Foo) -> u32 {
>>     f.
>> }
>>
>>
>> Put point after "f.", and type any number between (inclusive) 0 and 10,
>> and type TAB.  

Hi, I could reproduce this, if instead of TAB I type M-TAB (or the
equivalent C-M-i, both run completion-at-point).  Rust-rs-mode is not
needed (rust-mode from ELPA is the same).

I'm not sure yet this isn't a server bug.  After typing the 1, but
before C-M-i, the line reads:

    f.1

Point is now in LSP position (:line 6 :character 7).  After C-M-i, the
interaction with the server is:

    [client-request] (id:6) Wed Mar 22 10:17:53 2023:
    (:jsonrpc "2.0" :id 6 :method "textDocument/completion" :params
              (:textDocument (:uri "file:///tmp/tmp.wLa6UWw1Nf/src/lib.rs")
               :position (:line 6 :character 7)
               :context (:triggerKind 1)))
    [server-reply] (id:6) Wed Mar 22 10:17:53 2023:
    (:jsonrpc "2.0" :id 6 :result
              (:isIncomplete t :items
                             [(:label "0" :kind 5 :detail "u32" :filterText "0"
                                          :textEdit (:range (:start (:line 6 :character 7)
                                                             :end (:line 6 :character 7))
                                                     :newText "0"))
                              (:label "1" :kind 5 :detail "u32" :filterText "1"
                                          :textEdit (:range (:start (:line 6 :character 7)
                                                             :end (:line 6 :character 7))
                                                     :newText "1"))

   (some elements elided for readability)

Which means the server is offering to _insert_ an _additional_ '0', '1'
etc at position 7.  

Emacs/Eglot is not doing the right thing, but I don't think the server
is doing the right thing either.

Probably the server should be saying "I don't have completions for this
position given my current view of the document".  Maybe this could be
reported to the rust-analyzer people for their input.

However, given this "faulty" server exchange, I'm inclined to say
completion-at-point should offer to insert '0','1', and other
completions, and not immediately insert the "1".

João





  reply	other threads:[~2023-03-22 10:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21  2:33 bug#62315: 30.0.50; [BUG] Rust eglot tuple struct field completion Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-22  5:11 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-22 10:37   ` João Távora [this message]
2023-03-22 14:52     ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors

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=878rfpvzpe.fsf@gmail.com \
    --to=joaotavora@gmail.com \
    --cc=62315@debbugs.gnu.org \
    --cc=ruijie@netyu.xyz \
    /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.