search

SirVer / ultisnips

UltiSnips - The ultimate snippet solution for Vim. Send pull requests to SirVer/ultisnips!
GNU General Public License v3.0
7.53k stars 692 forks source link

Duplicate match dialog upon improper use of `extends` keyword in snippets #1559

Open kkew3 opened 1 week ago

kkew3 commented 1 week ago

This issue is related to #1519, but in a reproducible way.

In my context, I collect all math-related snippets in a file called tex_math.snippets, and I have a tex.snippets with content:

extends tex_math.snippets

# Some LaTeX-specific snippets

The issue occurs when I type any snippet in a a.tex file that is defined in tex_math.snippets, something like:

1: (frac) "math frac" (/Users/user/.vim/UltiSnips/tex_math.snippets:1)
2: (frac) "math frac" (/Users/user/.vim/UltiSnips/tex_math.snippets:1)

The cause of the issue is that according to UltiSnips doc (section UltiSnips-how-snippets-are-loaded), both tex_math.snippets and tex.snippets refer to snippets of tex filetype. Thus, by extending tex_math.snippets in tex.snippets, it might somehow trigger certain naming conflicts and causes any snippet defined in tex_math.snippets to be redefined. Interestingly, using extends tex rather than extends tex_math in tex.snippets won't trigger the issue.

Expected behavior:

Either error out, suggesting the user extends tex_math is an improper use of extends keyword, or behave as if the extends tex_math in tex.snippets is not present. In the latter case, all definitions in tex_math.snippets take effect in a a.tex file automatically, by definition.

Actual behavior:

As mentioned above, something like

1: (frac) "math frac" (/Users/user/.vim/UltiSnips/tex_math.snippets:1)
2: (frac) "math frac" (/Users/user/.vim/UltiSnips/tex_math.snippets:1)

is prompted, and the user must enter, e.g. 1<ENTER>, to select one, which IMHO is confusing and misleading.

Steps to reproduce

In the docker container:

  1. Open vim x.tex
  2. Type frac<TAB>
  3. The prompt mentioned above occurs
VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Jan  4 2024 03:08:50)
macOS version - x86_64

py:

2.7.18 (v2.7.18:8d21aa21f2, Apr 19 2020, 20:48:48)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]

py3:

3.11.9 (v3.11.9:de54cf5be3, Apr  2 2024, 07:12:50) [Clang 13.0.0 (clang-1300.0.29.30)]
kkew3 commented 1 week ago

It seems that under vim 9, set nocompatible needs be added to vimrc to reproduce the issue, whereas under vim 8 (in the docker environment), it's not necessary. That's why I didn't include this line in https://github.com/kkew3/ultisnips-issue1/blob/issue/docker/docker_vimrc.vim.