"self" from dot "." in python snippet problematic

[schivmeister]

When used for eg. with SuperTab for context-based completion, everything is fine except for:

math. == mathself.
math. == mathselfself.

It would be better if the completion here could be context-aware, so for eg. in Python we want "." to expand to "self" only when there is nothing before it, so we could have "something." and not "somethingself."

[kitmonisit]

I also encountered this issue.

[davidhalter]

I fixed it:
https://github.com/davidhalter/vim-snipmate

It's just one commit.
You have to put
let g:snipMateAllowMatchingDot = 0
into your vim config.

cheers!

[MarcWeber]

A complete bug report always contains both: a) what do you get and b) what do you expect instead. I don't see b).

[schivmeister]

You're right. Here it is as best as I can explain, very simply:

".something" == "self.something"
"something.something" == "something.something" (no change)

Both should work. That's what I expect. Anyway I've actually just removed the snippet for ".", and as of this moment my python.snippets is full of ugly customisations, but I'm lovin' it ;)

[MarcWeber]

I expect ".|something" expand to "self.something" where | is the cursor position. Did I get it?

[davidhalter]

Yes. You're right.
My "fix" is maybe not that good, because it probably not the right solution, because I'm not that much into vim scripts.
In my opinion, patterns should only work, if there is whitespace before the pattern (\n / \r are also whitespace).

[MarcWeber]

See pull request 84. Works here. If you tell me which custom snippets you're using breaking it I can debug it.

[davidhalter]

Actually it's like schivmeister wrote:
"self." results in "selfself."
"test()." results in "test()self."

Another example is the "" snippet, which produces normally init
"test()" results in test()init
But this behavior is not so much a problem, since I don't type an underline after brackets. However, typing a dot after brackets or a namespace is really normal and should definitely not result in another self.

I just tested python snippets, can't tell for others.
The snippets are not custom, they are just from the recommended snippets repo, here.
https://github.com/honza/snipmate-snippets

snippet .
self.
snippet _
${1:init}${2}

[MarcWeber]

"self." results in "selfself."

What is the problem? That's how snippets work. They look at the left. They find a '.'

[MarcWeber]

which should expand to self. - and that's what's happening. The main problem I have is that you don't talk about the cause. You're annoyed by something happening when typing self. (eg because you're using supertab or such - I have to guess your problems). So in the end it looks like you want context aware snippets which only appear in some cases. I was told that ultisnips has this build in - and snipmate provides a way to generate snippets "on the fly" - which could be used to implement the same feature. There is even a python example allowing to tab complete all functions defined in the same file for python.
Maybe we should allow multiple snippet sources - then one could be a function generating the ".self" snippet only when used at start of a line or behind ( [ + - etc. Again - I have to guess. And that's why you should think about improving your bug reports providing all context.

[schivmeister]

Crap, yes, you're absolutely right. I didn't look at it from the viewpoint of snipmate itself. The problem is actually just that - it should be "context aware".

[davidhalter]

Sorry, it's a little mess with those two issues (one being the pull request). This is my fault, sorry for that :-)

But in the pull request I wrote at the beginning, that I'm using supertab.

So, now that you understand what I want, I try to justify why I think this would be the right behavior.
Snippets don't look just to the left, they take the word to the left and look for a sníppet in that word.
e.g. with python snippets, "def" will expand to a full function, while "adef" will just generate a tab or start supertab. But this is not the same for the dot, as explained above.
So it's really up to the definition of a word. If you define a word as [^\s], my approach would be the right one, if a word is something more complicated, than the current implementation is the right one.
Since I knew, that some people would want the current behavior, I just wrote an option, which I think is the right thing to do here.

[MarcWeber]

Summary: You need a "no match" in snipmate so that supertab continues with completion.

I"m thinking about whether adding an "applies: BEFORE_CURSOR="^\s*$"" like line would be a nicer fix. Then much more context sensitive implementations could be added. In the end the question is whether we want to duplicate work - or whether someone should just merge xptemplate and make it read snippets files - because xptemplate (or ultisnips) are both more advanced". In the end the community will benefit from "less solutions" - because they will be of higher quality then.

The alternative solution would be to allow many "sources" - and generate the snippets on the fly. Then each implementation can take care about cursor location itself.

Another quick fix would be using a key different from but I agree that its not what you want.

[schivmeister]

Actually it's not so much of a big deal anymore as it was when I first reported this. I simply add my own snippets where needed and all is good. If I don't want "." I use, say "s." to expand to "self". I say not to go forward with anything and close this bug or go with something simple, like david's change(s).

[MarcWeber]

For PHP and most other languages I created a simple mapping:
inoremap $this-> or self. for pyhton etc.
That works pretty well for me :)
If you map t to in vim it also works in console.

You're right that it is used very often.

That's why snipmate is still used - it works good enough and is simple.