Open fannheyward opened 4 years ago
fwiw, at #252, the two reports of testers at the end pointed that snippet placeholder selection isn't working.
@oblitum selection in same file works as expect, but fails on another file, this also happens with RA+VSCode extension, https://github.com/rust-analyzer/rust-analyzer/issues/4551.
I've disabled selection for different file.
I only tested it in same file, didn't work for me. Meaning, just writing foo()
and expanding it I get to the end of the file as reported before, which I thought was the same report by @TimoFreiberg, but I'm not sure he was reporting the same trivial test now.
@oblitum can't reproduce the error in same file tests, selection will not go to the end of file.
k, fwiw, this is my setup:
vim version: NVIM v0.4.3
node version: v14.3.0
coc.nvim version: 0.0.78-3c774fbfa5
coc-rust-analyzer version: 0.7.2
rust-analyzer version: fbb8b88
coc.nivm directory: /home/francisco/.vim/plugged/coc.nvim
platform: linux
If @TimoFreiberg could chime in to state whether this report was about a trivial test in the same file or not, it would be great.
@oblitum reproduced your issue, very very weird behavior:
fn main() {
foo();
} // -- no new line EOF
this will add foo
function with selection on |}|
.
fn main() {
foo();
}
// -- with new line EOF
this will add foo
function with selection on todo!()
.
@fannheyward I confirm it's just like that.
Sorry for the delay, yeah I was also talking about that. Interesting that it seems to work as expected when there's a newline at the end - rustfmt removed that on save so I didn't notice that case.
@fannheyward realize that i'm late here but i just wanted to chime in on the decorations/inlay hints - currently it is supported for chained calls, but it'd be super nice to have for inferred types as well so that you could do e.g. let (tx, rx) = std::sync::mpsc::channel();
and analyzer would add decorations like let (tx: Sender<T>, rx: Receiver<T>) = std::sync::mpsc::channel();
@linde12 we can't do inlay hints in vim https://github.com/fannheyward/coc-rust-analyzer/issues/224
@fannheyward yeah i realize this but in nvim we could with the decoration API right? (i assume thats how inlayHints work now for chained calls?)
@fannheyward Ah, okay now i read that maybe that API doesn't work either (can't insert virtual text in the middle of "real" text) I understand, thanks!
Is https://rust-analyzer.github.io/manual.html#workspace-symbol anywhere planed or did I miss something by any chance? thanks
@pierreN try :CocList symbols
LSP 3.16 will add code action resolving support, need to switch to upstream when LSP 3.16 ready https://github.com/rust-analyzer/rust-analyzer/pull/6521
LSP 3.16 has file operations, which can be super useful for rust projects: https://github.com/rust-analyzer/rust-analyzer/pull/7009
@fannheyward "Range hover" is marked as done but the commit was reverted (https://github.com/fannheyward/coc-rust-analyzer/commit/d6b4f338a09d7c29d64815bab80a64d35f55fdaf), could you please contextualize? Happy to help with the implementation if you need it
@resolritter yes, I reverted and pushed it to another branch https://github.com/fannheyward/coc-rust-analyzer/tree/feat/range-hover, the problem is I did find a better way to make Range hover work with nnoremap K. Do you have any ideas?
the problem is I did find a better way to make Range hover work with nnoremap K. Do you have any ideas?
You're using getSelectedRange while expecting Vim to be in visual mode, however :<C-U>
kind of mappings (e.g. xmap <Plug>(coc-codeaction-selected)
) exit visual mode before executing the range and therefore that check will not pass.
While you could use <cmd>
mappings to avoid exiting visual mode, exiting is needed to get the visual mode range with '<
and '>
like here (as far as I'm aware it's not possible to do that while staying in visual mode, you have to exit it first for those marks' positions to be updated).
So, in short, the solution is to make the mapping work like xmap <Plug>(coc-codeaction-selected)
where you'll detect visualmode()
when the mapping is triggered, not after. Here's the doCodeAction code for reference and you'll see that it fetches the visual range using the marks' positions as mentioned.
@resolritter sorry for the delay and thank you for your help, I'm busy today, will check this next week.
For range hover, you need mappings like vnoremap <silent> K <cmd>call CocActionAsync('doHover')<CR>
to work.
Almost fn
will return something. I felt uncomfortable when use fn
snippet but not have a placeholder after braces. It need to be like this:
fn {0}({1}) -> {2} {
{3}
}
If you jump to place holder 2 it will contain available ->
for you, you just need to fill in the second placeholder. If you don't, jump to the third placeholder and ->
disappear.
@HungPham3112 can't reproduce, in my tests, the fn
snippet didn't contain ->
.
@HungPham3112 can't reproduce, in my tests, the
fn
snippet didn't contain->
.
I suggest the new fn
snippet contain ->
. I said it need to be. Sorry, because my English is bad
@HungPham3112 the snippets are came from rust-analyzer, post your feature request to rust-analyzer.
Any plans to implement Inlay Hints now that Vim supports virtual text?
@AceofSpades5757 this will add in coc.nvim
ResolveCodeAction