Completion problem inside some snippets when popup menu is disabled

Bug #1229334 reported by mMontu on 2013-09-23
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
UltiSnips
Confirmed
Low
Unassigned

Bug Description

First of all, thank you very much for sharing this great plugin!

I'm switching from snipmate; reading about the merging with UltiSnips I really liked the statement: "A rock solid plugin is more important than fancy features which break from time to time".

I don't like using the popup menu, so I use "set cot=". I've just found that this setting affect some plugin functionality. This problem was reproduced on a clean installation of gVim with no other plugin:

1) `:new`
2) on insert mode insert the following three lines:

   temp1
   temp2
   temp3

3) On new a line, in insert mode typing `bbox<tab>te<c-p><c-p><esc>` leads to

##############################################################################
# temp2 #
##############################################################################

4) Issuing `set cot=` and repeating step 3 leads to

##############################################################################
# tetemp2 #
##############################################################################

The output of :py import sys; print sys.version:
    2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)]

SirVer (sirver) wrote :

The popup menu is only in marks inofficial branch which is no longer rock solid I am afraid :(. I cannot offer support for this.

I can only give support for branches from github/ultisnips or here on launchpad.

Or did I misunderstand something here?

Changed in ultisnips:
status: New → Incomplete
mMontu (mmontu) wrote :

The problem I have explained occurs with regular usage of popup menu, i.e., the one that appears without any plugin when one start typing a word and then use Ctrl-n.

But maybe I'm the one who misunderstood some point.
I intended to stay on the rock solid plugin, so I've downloaded the main branch of UltiSnips 2.0 from https://github.com/SirVer/ultisnips/tree/master. I thought that this branch was the one which is kept in sync with Lauchpad.
Is this the latest official version?

SirVer (sirver) wrote :

Oh, I am sorry I misunderstood.

Yes, this version is official and stays in sync with launchpad, so you are on the right track there.

However, I am unable to reproduce - the snippet behaves correctly for me under macvim. Could you provide me with a minimal vim config that reproduces the problem for you and (if possible) a screencapture that shows the problem?

After I type what you wrote, my file looks like this:

temp1
temp2
temp3
#######################################################################
# te #
#######################################################################

Which is correct imho. However, I never see a completion menu in all those steps.

mMontu (mmontu) wrote :

No problems, actually it was my fault mention the merge discussion and skipping making it clear that I decided for the official UltiSnips.

I'm able to reproduce this problem in a fresh new installation of gVim on Windows, with an empty .vimrc (_vimrc on this OS) and renaming the ultisnips directory to .vim (vimfiles on this system). The empty .vimrc is significant for some options, as 'compatible'.

Maybe my explanation isn't very clear; on step 3, after inserting "te", it is necessary to hit Ctrl-p twice, in order to trigger word completion. Ctrlp is is the default, as explained in :h 24.3 and :h i_CTRL-P, but maybe you have some mapping that overwrites it.
If you still don't see any completion menu it is possible that you have set 'cot' option to something different from the default (which can be restored with :set cot&).

Then I think the expected behavior is "temp2", as show below step 3. The problem I see is that when option 'cot' is changed the text gets wrong when you press Ctrl-P more than once - which leads to output after step 4.

SirVer (sirver) wrote :

Thanks for the explanation. I cannot reproduce this still - while the completion dialogue is shown the snippet is messed up, but as soon as I either press <esc> or accept the current selection UltiSnips figures out what is going on. This is on mac using macvim.

there are subtle differences between Vims on different systems, so your issues is likely very real and might be that gvim is not sending the cursor moved autocommand. To make absolutely sure that I am in the same situation that you are please attach a minimal vim config dir (i.e. in a zip) that shows the problem and if possible send a screen capture showing the behavior for you.

SirVer (sirver) wrote :

with cot= I see some weird behavior but not as bad as you describe in the bug report.

mMontu (mmontu) wrote :

Hi SirVer. after "set cot=" is issued, the behavior is that the word typed before starting completion is repeated after multiple Ctrl-p or Ctrl-n is issued.

When cot contains the default configuration it causes the completion menu to be displayed, and then no problem occurs at all.

Actually, there is nothing to attach as a vim config. As I said, I'm able to reproduce this problem with an empty .vimrc (by empty I really mean a 0 byte file), and .vim contains only UltiSnips files (as the one created by $ git clone https://github.com/SirVer/ultisnips.git ~/.vim

I'm attaching an image of the problem.

My knowledge of python is very limited, but if you can give some direction I can try to debug it as you are unable to reproduce it.

SirVer (sirver) wrote :

Thanks for providing the additional information! I now see the problem.

As for debugging - this is very likely not a Python issues but a Vim issues. Vim seems to send out a different set of CursorMovedI commands when there is a overlay as when there is not. If you want to try to debug it, try adding debug statements in the cursor_moved functions in __init__.py (there is a convenience method debug.debug that prints to a file, because vim eats stdout).

I hope there is something we can do here - vim is super inconsistent with its behavior and one has to script workarounds for all kind of problems.

Launchpad Janitor (janitor) wrote :

[Expired for UltiSnips because there has been no activity for 60 days.]

Changed in ultisnips:
status: Incomplete → Expired
SirVer (sirver) wrote :

Setting to confirmed - though I do not have any current plans on working on this. Help is welcome.

Changed in ultisnips:
status: Expired → Confirmed
importance: Undecided → Low
mMontu (mmontu) wrote :

Thanks for keeping it alive, it will be nice to have it solved someday.

Actually I think it is related to this problem, https://github.com/SirVer/ultisnips/pull/104#issuecomment-28310444, so it is possible that it gets solved as a side effect.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments