Ultisnips cannot detect default user folder for NeoVim on Windows.

[xarthurx]

Expected behavior: I can edit my own snippets when using :UltiSnipsEdit.

Actual behavior: A message pop up:

UltiSnips was not able to find a default directory for snippets. Do you have a .vim directory? Try :UltiSnipsEdit! instead of :UltiSnipsEdit.

Steps to reproduce

1. Install UltiSnips for Neovim using vim-plug on Windows 10.

2. type :UltiSnipsEdit.

PS.1: If I use :UltiSnipsEdit!. only the official snips from vim-snippets was listed.

PS.2: I tried adding dirs and runtimes in the init.vim file, but things don't get better. Is it because ultisnips only check the $XDG_CONFIG folder for linux machines, but not $LOCALAPPDATA where Nvim is installed on Windows?

---

• Operating System: Windows 10
• Vim Version: Neovim latest.
• UltiSnips Version: latest.
• Python inside Vim: 3.7
• Docker repo/vimrc:

[xarthurx]

Additional notes:

If I set g:UltiSnipsSnippetDirectories to a dir with an absolute path, then I can edit my own snippets. But once I include the keyword UltiSnips in that settings (or use it only as the default settings), the above issue will occur.

[Yonshoku]

Same problem, vim-plug, win10

[FruitDZign]

I have the exact same issue as xarthurx and Yonshoku (neovim v0.5.0-811 and then neovim v0.5.0-828 64 bits + Windows 10 20H2 + Python 3.7 + vim-plug) Even when setting the absolute path of my snippets or adjusting the runtimepath variable I had the same error.

[cristianUrbina]

You need to create a directory called UltiSnips inside ~/.vim directory mkdir ~/.vim/UltiSnips

[SirVer]

I have no idea what Neovim does differently so this does not work. Please try reproducing with Vanilla Vim. I'll leave the ticket open for a while until I see a repro with Vanilla Vim, otherwise I assume this is a neovim only problem.

This issue was deprioritized due to it only affecting Neovim and not core Vim.

Why is Neovim only best-effort?

UltiSnips maintenance is a lot of work. Reproducing bug reports is tedious, slow and error prone. The current maintainers have to limit their scope to provide a reasonable level of service to the community.

Neovim should work with any plugin that core vim works with. But in the past, Neovim support has been difficult for UltiSnips: It regularly had bugs that did not affect the core Vim distributions, i.e. Vim, gVim, MacVim, and Vim for Windows and its testing approach required a completely separate code path from core as well. Therefore, currently Neovim bugs are considered on a best effort basis.

UltiSnips is looking for an additional maintainer that is interested in bringing the Neovim level of service on par with core Vim. If you are interested in helping out, please reach out to SirVer.

[xarthurx]

I think the issue may because UltiSnips does not recognize the neovim folder structure, i.e. everything inside ~/nvim instead of ~/.vim. Would it be possible to simply add an option to add a different default folder?

[SirVer]

@xarthurx UltiSnips is using rtp like any Vim plugin should. It does not have a "default folder" per se. I have no idea if and if yes, how Neovim has deviated from this. If a simple patch is possible, I gladly accept a pull request.

[igor-ribeiro]

BTW, it works if you create the folder inside ~/.config/nvim/ instead of ~/.vim/

[Tsingv]

I'm using neovim now, and I use let g:UltiSnipsSnippetDirectories = ["~/.config/nvim/UltiSnips"] in my init.vim, which probably fixed the issue. (Attention to the '[')

Because I found the origin g:UltiSnipsSnippetDirectories is set to ['UltiSnips'] only, it can't be expand to an absolute path. Besides, my &runtimepath has no ~/.config/nvim so Path(snippet_dir).parent can't be neovim's "dot_vim_dir". If you specify g:UltiSnipsSnippetDirectories, it would return directly without traverse &runtimepath.

[marcdeop]

I created a PR that should fix this. At least it allows NeoVim and Vim to work properly on my system :-)

I cannot test on windows but it would be appreciated if anybody could try (@xarthurx perhaps?)

FYI: what @igor-ribeiro mentions here is because get_dot_vim() only handles one file which happens to be ~/.config/nvim/ (only due to ordering in the code :man_shrugging: )