[ANN] hl-indent-scope available on Melpa!

Interesting. I looked at the code, and it seems like you construct a tree at various places and use that to set the bounds of overlays, or something like that. Do you mind talking a bit about that implementation? e.g. why you did that instead of using a loop that doesn't cons (i.e. one that wouldn't create garbage, or as much, within the font-locking cycle)

Right, the method used uses a tree to define "scope" which are then used as delimiters for highlighting syntax. This has some pros/cons, one pro is the highlighting can be more meaningful, compared to simply highlighting the indentation you see: [see screenshot](https://user-images.githubusercontent.com/1869379/182262397-f4dd8950-8554-4cc2-a035-3ee0bace91e1.png). Not sure exactly what you mean by `a loop that doesn't cons`, are you saying a loop instead of recursion causes less garbage? I wasn't aware of this, but if that's the case, this could be converted into a loop I suppose.

When it comes to font-locking, it can be difficult to put into words. What I mean is, maybe you don't need to build a tree at all. Instead, the font-lock matcher function should be able to find the bounds of the list depth at point when it is called (e.g. using `syntax-ppss`), make the overlay (e.g. [in the font-lock keywords](https://github.com/alphapapa/obvious.el/blob/bb79c6a8fe514e1339004578e231662cc63b9105/obvious.el#L41)), and then set the match data and return non-nil, so font-lock can call it again at the next point it needs to fontify, if necessary ([example](https://github.com/alphapapa/obvious.el/blob/bb79c6a8fe514e1339004578e231662cc63b9105/obvious.el#L182)). In other words, AFAIK, when it comes to font-lock code, one should try to do the minimum necessary, for the sake of performance. That includes avoiding the creation of garbage that will need to be collected during font-locking. That's about the best explanation I can give in English, I think. :) Beyond that, I can point to code I've written in [prism](https://github.com/alphapapa/prism.el/blob/master/prism.el#L355) and [obvious](https://github.com/alphapapa/obvious.el/blob/master/obvious.el#L123) that use font-lock matching.

As far as I can see building a tree is needed as simply using `syntax-ppss` assumes every level is included - which isn't always the case (some can be skipped). The tree is limited by the beginning/end bounds (extended to the root-level), so it's not building a tree of the whole buffer, but I'll check on the lines you've given to see if the can be further optimized.