I'm not much of a python pro, but it appears the correct
way to iterate is next(i) instead of i.next(). i.next() has
been renamed to i.__next__() on python3, but next(i) works on both.
Pasted below is the following test script ran through python
2.6, 2.7, and 3.3:
i = iter("1,2".split(","))
next(i)
i.next()
i.__next__()
next(i)
Python 2.6.8 (unknown, Jan 26 2013, 14:35:25)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> i = iter("1,2".split(","))
>>> next(i)
'1'
>>> i.next()
'2'
>>> i.__next__()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'listiterator' object has no attribute '__next__'
>>> next(i)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
>>>
Python 2.7.6 (default, Dec 6 2013, 20:05:37)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> i = iter("1,2".split(","))
>>> next(i)
'1'
>>> i.next()
'2'
>>> i.__next__()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'listiterator' object has no attribute '__next__'
>>> next(i)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
>>>
Python 3.3.3 (default, Jan 2 2014, 19:09:02)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> i = iter("1,2".split(","))
>>> next(i)
'1'
>>> i.next()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'list_iterator' object has no attribute 'next'
>>> i.__next__()
'2'
>>> next(i)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
>>>
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
This commit adds a lot of the basic Sass directives used in Sass script.
Documentation can be found at:
http://sass-lang.com/documentation/file.SASS_REFERENCE.html
I decided to use regular expressions for the triggers, since typing the
`@` may be too cumbersome to require it to always be included, but is
likely happening due to muscle memory too often to leave it out. Regular
expressions give us the flexibility to have it both ways in this case.
Now that we have separated the two `for` loop snippet triggers by
changing the one that counts down from "for" to "ford", it feels more
and more like "ford" is a variant of "for" so I am moving it after it in
the file. Also, alphabetical.
As suggested by @SirVer[1], having `Things[i]` be pre-populated in the
body of the `for` loop snippets is not very useful given the merits of
autocompletion. This commit simplifies these bodies by simply using
`${VISUAL}$0`.
[1]: https://github.com/SirVer/ultisnips/pull/123/files#r8686533
`for` loops usually appear at the beginning of the line. This commit
makes these snippets more context-aware by adding the "b" option that
prevents them from being triggered if they are preceded with something
other than whitespace, as suggested by @SirVer[1].
[1]: https://github.com/SirVer/ultisnips/pull/123/files#r8686514
As suggested by @SirVer[1], this commit changes the trigger of the
JavaScript `for` snippet that counts down from "for" to "ford". Since
"for" is used pretty often, this will prevent people from needing to
select which one they want from the menu each time.
[1]: https://github.com/SirVer/ultisnips/pull/123/files#r8686514
More specifically than "faster" and not faster, these snippets count
down and count up, respectively. Adding this information to the
descriptions will help people make the correct decision.
The `Things.length` part of the JS `for` snippet previously did not
include the `.length` portion. Using some regex replacement, we can
include this bit in the placeholder while still only using the `Things`
bit inside the `for` loop. This should make the snippet slightly more
pleasant to use.
The previous version of this snippet referenced the object's length on
each iteration of the loop. This adds unnecessary overhead, causing the
loop to be slower. While this will not make much of a difference in many
cases, if the for loop was to be used on a large object or in a tight
loop, it would degrade performance.
Perhaps more importantly, if you were to not cache the length of a live
query, such as DOM queries, you would see significant performance
degradation. If nothing else, this adjustment to the snippet sets things
up for success in more scenarios.
The "b" trigger option will require that the snippet be expanded only if
it is at the "beginning of the line", that is, only whitespace may
precede the tab trigger.
As suggested by @SirVer[1], this commit adds the "b" tab trigger option
to all of the JavaScript console API snippets.
[1]: https://github.com/SirVer/ultisnips/pull/122/files#r8665940
