So imagine you want to find all the indexes of 'thing' in a list with more than one of 'thing'.
How do i do that? [scratchblocks](index (2) of [thing] in ( list [thing][thal][thlot][thing] :: list) :: list) // the list has 2 of 'thing'. We are looking for a specific 'thing'[/scratchblocks]
I have an indcies of block and I think it can be used for what your after
how do you make the indices block
But you should be able to save the image from my 1st post and then drag it into Snap! and the block will appear
I kinda need a simpler way to do this.
Why? If the blocks @cymplecy gave you work.
I want to combine these blocks, and i dont want to use one custom block for another one
Why not?
The whole power of a programming language is that once you've written a block it's just as good as a primitive -- you can layer abstractions on top of abstractions to get complex behaviors out of simple pieces.
this is super nice and elegant, @ego-lay_atman-bay !
[edit] wow, it's actually ... brilliant!
Thanks!
Why ALL BUT FIRST OF (NUMBERS FROM 0 ...) instead of NUMBERS FROM 1?
why use FOR (I) = () to () rather than (#) FOR EACH (ITEM) in list utilities
because in your way, if the list length is zero, numbers from 1 to zero will report a two item list ([1],[0]) instead of a zero item list, and then the keep block will then be looking for a item (1) of and and item (0) of an empty list, none of which exist.
Oh. I keep getting in trouble because of that. We should have made it only work upward. 
I've been trying to convince Jens that there should be a menu input NUMBERS FROM _ [TO/UP TO] _ to make everyone happy.
Aw, c'mon, Brian, you're a mathematician, the number line goes both ways! Constraining it to ascending order is just a quirky special case for a certain (small!) number of use cases. We want to enable all kinds of number play, including use cases such as this one:
I don't think the applications are either quirky or small in number. But in any case, what I'm suggesting isn't to undo the original decision, even though it's not the one I would have made; what I'm suggesting is to let users get the behavior they want (and also to give them some subtle warning about Snap!'s strange behavior and why their program isn't working).
For simple cases like this, I just can't be bothered loading it in 
FWIW, I'm with @bh in this. In my experience cases where one requires numbers to be strictly ascending are (far) more frequent than those where descending order may be applicable, too. I find myself more than once either using @ego-lay_atman-bay 's workaround:
,
or moving to an altogether different solution.
IMAO the default operational mode of numbers should be strictly ascending (by 1 at a time), with an optional step parameter that may be any number but 0, Infinity, and -Infinity.