Improve highlighting of in.

[mcol]

This highlights both in keywords in multi-iterable for loops (#148), and adds highlighting in the cases where in is used to check if an element is contained in an array, as in if 2 in [1, 2, 3].

[tpapp]

Can you please add some tests, eg the cases mentioned in #148? You will find examples in the current test script with names like julia--test-...-font-lock.

[non-Jedi]

in is functioning as just a normal infix function when not used in a for-loop and so shouldn't be font-locked as a keyword.

[mcol]

@non-Jedi I didn't see your comment before pushing my commit. As a newbie user, I think it would help to font-lock in also outside a loop, but I can revert that.

[non-Jedi]

My most convincing objection is that in(x, y) has the exact same syntactical meaning as x in y (it even parses the same; try it yourself with Meta.parse). If we font-lock in for x in y, it doesn't make sense not to font-lock it for in(x, y), and if we're font-locking in(x, y), it's only going to look confusing next to the non-font-locked foo(x, y).

I kinda get it. Infix function symbols are parsed in a way that's different from normal symbols. isa is the same way. For consistency's sake, if we were going to font-lock in and isa differently we would also need to font-lock all in-fix operators (+, *, etc.).

[mcol]

Sure, the more I thought of that and played with edge cases, the more I agree with you. Clearly, that makes a fix much harder, as you mentioned in the issue. I still have a couple ideas I'd like to try, but it'll be a few days before I can get back to this.

[tpapp]

FWIW, I would prefer just font-locking in for. I realize it is not easy to do this.

[non-Jedi]

@mcol, would you be interested in updating this pull request just to add the multi-loop in test cases and mark them as broken?