span.cm-bracket. Since everything else does work it's no big deal (one can just set the default color and change every other color), but I thought I'd notify you.
end, although there might be something strange going on with my LT installation since I was pretty sure that's new behaviour
printlnetc treated as builtin? I don't quite see why Types, special values like
Infand those functions should be treated the same.
columncheck is mine though, the idea is to treat both
foo() =as definitions
columncheck: I totally forgot about that way to define functions! It does make sense to style them the same as the ones defined by
function, although that check is not enough. Even a function call starting in column zero will trigger the definition-style, so a check whether there's an
=after the function call should probably be added. That should cover all cases, but I'm not experienced enough in Julia to be sure about that.
foo(...) = ...is that you have to parse everything between the brackets before you get to the
=, and even then it breaks when the
=is on a new line. I might make it more precise in future but for now I think overshooting is probably better than undershooting
nvariables in the current scope and emit the style
variable-1, the second
-75and so on. Of course those colors aren't the same in different documents and there are probably additional issues, but it's all I could come up with for now.
I really like a lot of these ideas, but it's really a question of feasibility – at least in the short term, it's probably best to have either a very basic version of this or none at all, rather than spending weeks on something that may not work well.
I think the best thing will be to split out this functionality into a separate plugin. It should be easy to switch on and off, so that themes (including custom ones like yours) work just as well with or without it. I realise that at the moment I've stopped you from having different styles for function calls, so that will be fixed when I do this.
It's definitely a challenge to strike the balance between having distinct colours and not making the editor look like a pile of skittles, but hopefully with enough tweaking I can get something decent going. Unfortunately I don't have nearly enough time to actually do work using the editor at the moment.
I agree that most changes would definitely need a lot of time to tweak and get just right, but the two I proposed should be relatively straightforward to implement (unfortunately I don't have all that much time rght now, but I'll take a look at your js and see if I can figure out what you're doing). The second one should also address the probem with conventional styles not working, since any function call would have two classes: The one from the definition of said class and another one that marks them as a function. If the first one doesn't provide any information regarding color than the "conventional fallback" can kick in and deliver the same look as before your changes.
A plugin for LT called
match-highlighter provides a nice way to visualize any occurences of an variable (much like Matlab), so that definitely helps. Actually, it highlights anything that's called the same as the word the cursor is over - that could/should probably be tweaked to only apply...
Cool, it would be great if you could have a look at doing this – here's a couple of notes:
.cm-def(function definition) and
.cm-variable-2(function call) nodes from outputted DOM and apply additional CSS classes as appropriate. (Like I said, I like this idea so I'll probably have a go at it if you don't – but I don't know anything about writing CodeMirror addons yet.)
match-highlighter is neat – I might have it enabled by default if it plays well with unicode.
re 2: The CodeMirror manual (see http://codemirror.net/doc/manual.html , Writing CodeMirror Modes) says it is possible.
Regarding unicode: Ah, well... Nope,
match-highlighter can't deal with it - but neither can your implementation of the parser. So right now it doesn't matter ;)