Impossible for the common “highlight a single file”-highlighters. It does only know about the currently highlighted module Foo, nothing about Bar. Therefore it cant know if Bar.foo() is calling into a macro or into a function.
NobbZ
3
tmbb
My priorities regarding features are (roughly in order):
- Make it so that when the user places the cursor over a matched delimiter (
(...) %{...} {...} <<...>> [...] %Struct{...}), both delimiters (left and right) are highlighted. I can do this with few code changes and ~ 20 lines of javascript). - Add iex lexer for doctests
- Add lexer for elixir stacktraces
- Add general eex lexer
- Add html.eex lexer
- Add CSS lexer
- Add Javascript lexer (this will allow me highlight CSS and Javascript inside and HTML file)
2
PatNowak
tmbb
Added the first feature:
- Make it so that when the user places the cursor over a matched delimiter (
(...) %{...} {...} <<...>> [...] %Struct{...}), both delimiters (left and right) are highlighted.
This change is already reflected in the demo. You can visit the website and place the cursor over the delimiters. The matching delimiter will be highlighted. In the HTML5 examples matching open and closing tags will also be highlighted if you place the cursor over one of the tags. Try it, it’s cool.
2
OvermindDL1
tmbb
OvermindDL1
tmbb
Ahaha, it’s a PEG parser. As long as the grammar definition is sound, it handles averything you throw at it. Supporting the highlighting of matching blocks and delimiters does have a noticeable impact on performance (for something as complex as the demo pages), but I think it’s worth it. But it’s still quite fast, probably thanks to ExSpirit!
1
OvermindDL1
Still tons of optimizations I can do, it is pretty ‘simple’ as far as previous PEG parsers I’ve written. I’m really tempted to change it to be a DSEL instead of function/macro composition… >.>
Though I’m guessing that you are parsing over every code block in your examples individually (all 100+ of them?!?) which would definitely be a lot slower than parsing over it once and pasting it in different places. ^.^
Good test to do in any case. 
0
tmbb
For my use case, the priority is having something that compiles fast in dev and is fast in :prod. I’d prefer something that’s no faster than what we have now but compiles faster in :dev than something which is faster but compiles slowly in :dev. But for other users, raw speed might be more important…
0