So I'm thinking about a novel way to think about syntax highlighting that I can implement for my text editor. I was thinking, what if the way we do it now - basically highlighting words instead of logical blocks - is retarded. Like you can see I've added a regexp to basically tune out all but the last item in each call chain, so that they're grayish and so that I pay attention to the actual function call. What are some other non-standard ideas for syntax highlight? What would you really want?

>>105980493 (OP)
>What are some other non-standard ideas for syntax highlight? What would you really want?
Highlighting each scope depth distinguishable, while preserving all semantics consistently in the highlight. Kind of like this package for Emacs: https://github.com/alphapapa/prism.el

>>105980595
It's nice there are alternative ideas like that out there, but this is definitely not what I like. It seems to be designed for languages that favor a lot of nesting, so basically Python, old school js as Lisp, it seems. I dislike the approach and the spahgetty code it results in, because I think it's good to keep code as flat as possible (visually speaking). I think I understand why Go opted out for method syntax which makes it so that methods are just functions with an extra set of parentheses on top.

>>105980493 (OP)
I don't like it, "document" is "document" and "Mode" is "Mode" no matter what you do with them, making them different just adds confusion

>>105980758
So, maybe you misunderstood. Picrel isn't like the perfect syntax highlight. There's some conflict between my regexp and Vim defaults that prevents code in parantheses or after == to be dimmed the way I described. The idea, however, is that in a call chain like a.b.c.d.E() all but E() are dimmed, so that you can focus on what's important, which is the function call.

>>105980493 (OP)
here's an idea
you select blocks of code in multiple files
and then you have a special tab that lists all those selections at once where you can see and edit them all
on save those blocks get saved to their actual place in their files

>>105981020
Even though it has northing to do with syntax highlighting, I like it, thanks anon! Totally doable and useful too, I myself often end up switching between multiple files via tabs or splits and it's not as comfy as you what you suggested.

Of course, while doable, it's clearly non trivial with all the edge cases and also I was thinking the process of selecting lines in the first place is kinda of cumbersome. But yeah, very cool idea overall.

>>105980493 (OP)
>What are some other non-standard ideas for syntax highlight? What would you really want?
The ideal would be representing the program text as a tree so arbitrary highlighting rules could be applied, like a cumulative tint added each time a function is called so you can visually see which functions are called more or less often, or where nested for loops are tinted deeper reds for each level of nesting

>>105981099
it would be very important to allow selection of multiple blocks within the same file

>>105981249
>nested for loops are tinted deeper reds for each level of nesting
good one

>>105980493 (OP)
Look into Projectional Editors, which the TLDR:
>instead of thinking in chars and strings, you think and edit in nodes for a tree
https://github.com/yairchu/awesome-structure-editors
https://www.youtube.com/watch?v=iN2PflvXUqQ
https://en.wikipedia.org/wiki/Structure_editor

>>105981300
Unironically, I've just implemented it

>>105981413
oh god no just no. There's a million reasons why structure editors completely failed.