If I setautotrigger = true, it will expand snippets on confirming a completion with Emmet (fixingolrtg/emmet-language-server#55), but it will also introduce a bug withrust_analyzer (#36823) that sends completeopts more dynamically. Triggering it manually withautotrigger = true fixes both issues, but triggering it manually withautotrigger = false doesn't solve the first one, and basically all other snippets also stop working for me, just inserting a label (abbr), not the actual contents.

If you have ways to solve those issues, I will accept that I was wrong about native completions. Otherwise, its state doesn't seem mature enough to recommend it. Although the following didn't form my opinion on the topic, you can also watch a person struggle with completions in a more entertaining form:https://youtu.be/tnlgQFQi2s4?si=UcrO1nCLwWrMUryh.

Sure we can create a wrapper for each edge case withCompleteDonePre or by changing the core completefunc powering the logic. Sure we can add wrappers to source custom LSP-like snippets from a JSON file by parsing the latter. But that's why I didn't recommend creating your own linter, and that's why I don't recommend touching native completions for now. Althoughblink.cmp, and a fairly newnvim-snippets plugin, just build uponvim.snippet, so I do understand the backend is there.

I haven't write rust in a while, so I just open an old project and tested what's mentioned in#36823. As you can see, I don't have the same issue:

Afaik I don't have anything weird in my setup, so maybe it's something that has been fixed in nightly recently but not in the latest stable. I have never experienced something like that with the ls I use. In any case, if there is any bug it's a good idea to post as an issue so that the team can fix it.

As for the video: these are the issues he had:

• Autoselection of the first option:completeopt has been a thing for years in vim. Setting an option shouldn't be an obstacle and no custom code is needed.
• Documentation: yes, you can't see the documentation by default, you need to write some custom code to see it. There is pr right now to add it with a simple opt (feat(lsp): vim.lsp.completion completionItem/resolve when completeopt=popup #32820 - it is stale at the moment because I think it needs another pr to be merged first, hopefully will be merged before the 0.12 release). I don't consider this an issue, many don't use docs (I personally don't, as they are distracting). I do consider this a missing feature, which can be important or not.
• Can't use luaSnip: Yes, you can't, you can only use lsp snippets. Many ls provide snippets, those can be used. Another option is to provide snippets as an lsp, there are some plugins to do that, for example (nvim-snippets)[https://github.com/garymjr/nvim-snippets]

Sure we can add wrappers to source custom LSP-like snippets from a JSON file by parsing the latter.

I mean, it's a wrapper of just 10 lines of code, not that you need to maintain a 1k monster. But it's just a simple solution if you want to use custom snippets. As I said, there are plugins for that too.

Taking all into account, my whole native completion setup is shorter than your (blink config)[https://github.com/shushtain/dot/blob/main/nvim/.config/nvim/lua/plugins/blink.lua] (and would be the same amount of lines if I added docs), so I don't think it's too complicated to use native.

Yes, as I said before, it has some limitations, and if you are not ok with those limitations there are plugins like blink that offer a lot more. My only comment was that "builtin completion works with snippets", as the original post (before editing) seemed to mention that it wasn't the case ("it adds missing snippet engine").

To be clear, I have never said "builtin is better than a plugin" or something like that. I just said that "Agree plugins offer more capabilities, but you can just use the builtin if you like what it offers.". Both are good options and you should use whatever offers what you want or need.

If you are on nightly, then what are we even talking about? I'm glad you don't have the same issues, but they are still reproducible in v0.11.5, and I don't have enough skills to debug them on my own. As mentioned at the top of the post, the guide is mostly for v0.11.5.

The reason I encourage people to install servers and write formatting recipes on their own is because it demystifies LSP instead of hiding useful settings. For example,conform.nvim is very nice for care-free default recipes, but configuring it further requires studying its API that could be spent getting to know the formatter itself, and learning to run its commands as processes.

Debugging LSP requests, however, is not something I wish upon new users, especially since it could indeed be solved already in v0.12. So, again, I won't change my recommendation in this case, unless at least those mentioned issues are solved.

blink.cmp not only solves all the bugs I spotted, but also provides better docs,snippets/ folder support, cmd and terminal completion, ghost text suggestions, etc. I don't force anyone to use it, and I constantly test the native implementation to see if the problems are gone, because I also would like to switch.

Sorry, I didn't know nightly users can't comment on github. Just wanted to comment one little thing. You said:

The reason I encourage people to install servers and write formatting recipes on their own is because it demystifies LSP instead of hiding useful settings.

And you shared a lengthy autocmd to show how to write that recipe. That's great! Sad that you consider then

Sure we can create a wrapper for each edge case with CompleteDonePre or by changing the core completefunc powering the logic. Sure we can add wrappers to source custom LSP-like snippets from a JSON file by parsing the latter. But that's why I didn't recommend creating your own linter, and that's why I don't recommend touching native completions for now.

when the snippets wrapper is literally 10 loc. Why writing your own recipe for formatting is worth but not for snippets?

Debugging LSP requests, however, is not something I wish upon new users

I have never had to debug any LSP request. If I have a bug, I report it, and let the people that knows to fix it.

Funny how I just said "builtin completion works with snippets, neovim has a builtin snippet engine." to end up being borbarded with problems with "docs, snippets/ folder support, cmd and terminal completion, ghost text suggestions", none of them go against what I previously stated which is objetively true. And funny enough none of that (except snippets/ folder support) has anything to do with snippets. But hey, it's your guide and I just wanted to give some input.

And I repeat: "Great guide".

So, the course of events: I wrote that native snippet expansion is problematic (but in a nicer form). You replied that it works 100%. I showed you the issues. You said you can't reproduce themin a different version of the program. What should I do with that information? Thank you for your input, I guess. I spent some time reproducing all the mentioned issues, just to make sure I'm not that dumb...

I did make useful corrections based on your comments about "the engine". But you must understand that nightly and stable experiences are different. That's why I said that one day native completion will be better than anything we have so far, because it moves in the right direction. However, I can't ignore the existing issues, even if they are solved in nightly. I'm not writing docs for 10 years, I'm creating a snapshot of opinionated recommendations for specific version at this specific moment. Is that okay?

And I did explain why writing custom "format on save" is valuable. Because you learn tools you can use from anywhere. You learn to format JSON from shell after generating it in any program. The same with setting up all LSP config fields: you learn you can set up any LSP server, even ifnvim-lspconfig doesn't have a recipe.

When you write a wrapper to see docs, to gather snippets, to fix bugs with completion filtering, you still learn something. But those are editor-specific skills. Not all APIs are created equal. Feel free to make your own guide on writing a lean completion setup that covers the gaps.

Lastly, no matter how much you speculate about the length of my dotfiles,blink.cmp works OOTB with 1-3 lines of code required to install it. I'm sorry I had the audacity to set some custom icons in my personal config. How dare I...

I believe we are done talking about anything substantial. Goodbye.

Thanks! I didn't know that.