Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defaulting value to another value bug #59

Closed
bogdan opened this issue Oct 10, 2011 · 10 comments
Closed

Defaulting value to another value bug #59

bogdan opened this issue Oct 10, 2011 · 10 comments

Comments

@bogdan
Copy link

bogdan commented Oct 10, 2011

Let's say we have the following skippet:

k.snippet:

:${1:} => ${2:$1}

Key sequence: ik<Tab>hello<Tab> should:

  • enter insert mode
  • expand the snippet
  • fill in first value
  • set second value default to first value
  • highlight second value, but it is not
@MarcWeber
Copy link
Collaborator

I don't know whether this is even supported - neither do I think I would
support it because my feeling is that the engine behind xptemplate
already supports this all (give it a try and report your results,
please).
So I'd change this issue into "let's merge xptemplate and snipmate" -
but I don't have time to work on it at the moment :(

About your description:
Its not accurate enough because you don't know what the current state
is. So I've tested it and report my results:
I don't even get the second placeholder to jump to by using tab.
The second place holder appears if you replace the $1 within ${2:$1} by
a value such as "word".

@lucapette
Copy link

I'm quite sure that current vim-snipmate implementation doesn't provide this feature. So, if we agree I could label this issue as a feature request and change the title to "support for using placeholders for default values" or something better you could sugget. We can leave it open until we find a good way to do it.

P.S. @MarcWeber What Do you think about labeling issues? I can do it if you like the idea.

@bogdan
Copy link
Author

bogdan commented Oct 11, 2011

I use the following snippet with original repo and this fork without any problem for ages:

let(:${1:}) do
  Factory.create(:${2:$1})
end

If it is working and was working than this issue is bug.

@MarcWeber
Copy link
Collaborator

let(:${1:}) do
  Factory.create(:${2:$1})
end

is working (I confirm) - at least partially: The cursor is put before
the ${2 but the word is not selected in any way.

:${1:} => ${2:$1}
is not.

So can you describe in more detail what broke exactly?

@bogdan
Copy link
Author

bogdan commented Oct 18, 2011

Broken thing is:

${2 but the word is not selected in any way.

This was working before.

@MarcWeber
Copy link
Collaborator

Excerpts from Bogdan Gusiev's message of Tue Oct 18 10:25:41 +0200 2011:

This was working before.
which commit?

@bogdan
Copy link
Author

bogdan commented Oct 18, 2011

Did a little more investigation and found out that not selected second value bug appear only when ${1} do not have default value.
And it doesn't work even with msanders's version.

So the following:

let(:${1:name}) do
  Factory.create(:${2:$1})
end

Works

And the following:

let(:${1:}) do
  Factory.create(:${2:$1})
end

Doesn't work.

Sorry for messing you, Marc.
If you consider this not a bug - you may close it - as it is behavior of the original version.

@MarcWeber
Copy link
Collaborator

Excerpts from Bogdan Gusiev's message of Tue Oct 18 11:12:41 +0200 2011:

Sorry for messing you, Marc.
If you consider this not a bug - you may close it - as it is behavior of the original version.
You're kidding. Of course its a bug :)
I checked an older version and saw it doesn't work either. That's why I
had to ask. Your investigation however gives more details. Would you
mind adding a bug section the README describing the problem for now?
Eventually somebody with the given skill level required picks it up and
solves it. I don't want to dive into the details of the snipmate engine
at this point in time - and before doing so I'd like to investigate
xpemplate as well which I talked about earlier.

I'd prefer the README because its more likely that people read it and
its distributed compared to the github bug tracker.

MarcWeber pushed a commit that referenced this issue Oct 18, 2011
MarcWeber added a commit that referenced this issue Oct 18, 2011
@ajzafar
Copy link
Collaborator

ajzafar commented Jun 16, 2013

This happens because of the way SnipMate keeps track of and updates everything. It simply stores the line number and column number of where tab stops and variables start and end. This simplistic way means that there's no real way to tell that in ${2:$1} the second tabstop starts before that variable. SnipMate updates the variable just fine, but can't tell that it needs to also update where the tabstop ends.

There is no easy way to fix this using the current implementation. However, I'm going to leave this issue open in case I manage to think of something clever.

@ajzafar
Copy link
Collaborator

ajzafar commented Feb 10, 2015

This seems to have been fixed along with the work on allowing nested stops.

Note: This is only fixed for g:snipMate.snippet_version = 1.

@ajzafar ajzafar closed this as completed Feb 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants