On this side, I'm not a bot, and fortunately even in 2025 nobody on the internet knows that you are a dog.
The ease of use to highlight static text via Arborium seems nice:
<script src="arborium.iife.js"></script>
<pre><code class="language-python">
def hello(name):
print("Hello " + name);
</code></pre>
And how would one add SCAD support?
The code isn't minified so you can see how they do it by looking at the `doHighlight()` function here https://arborium.bearcove.eu/pkg/app.generated.js
Hmm .. and the approach already shows its weaknesses when I play with it: When I search for something on the page, it gives me twice as many hits as there are. And jumps around two times to each hit when I use the "next" button.
I wonder if that is fixable.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
https://developer.mozilla.org/en-US/docs/Web/API/Highlight
All the trickery vanishes and you get first-class CSS support.
https://github.blog/engineering/architecture-optimization/cr...
It’s not a new discovery, I just didn’t know docs.rs (intentionally) wasn’t blocking this. Cf https://docs.rs/pwnies/0.0.13/pwnies/
(This all makes more sense if you read the blog post instead of the direct arborium link: https://fasterthanli.me/articles/my-gift-to-the-rust-docs-te...)
I'm happy to see that tree sitter highlighting on the web is finally a thing. This seems really solid although the bundle size is a lot.
But then, on the other hand, I had given up on a scratch code editor for a game development project I'm working on, and just loosely wrapped up the monaco editor which I'm guessing is going to be pretty bare when I actually get around to trying to code with it, in browser (I'm aware that it is robust, but from what I gather, a lot of its features come from third-party dev as a way to keep the core functionality pure). Given that I want to be able to script in C# (aside from just js/ts), I was sure I was going to have to figure something complicated out.
But, honestly, I think this solves all of my most concerning issues! What a sweet little library!
[0] https://magnitce-code-example-e81613.gitlab.io/ (please excuse the unfinished-ness; I'm working on a JSDoc-to-documentation library that automates the documentation for me so there are minor issues, like the install text not changing on selection)
My favorite is nvim-treesitter-textobjects which gives you dozens of new targets for vim motions, such as a function call or the condition of a loop.
Tree-sitter is a parser generator tool and an incremental parsing library. It can build a concrete syntax tree for a source file and efficiently update the syntax tree as the source file is edited.
They also load 1 mb of fonts. In total, this page is close to 3 mb.
Also, when you select a language, the grammar file gets downloaded twice.
You can use it as a normal Rust library, or you can use the JavaScript/WASM wrapper to highlight source code on a web page.
Just wanted to note that tree-sitter is lower-level and more general: it's an incremental parser that is specialised for gracefully and efficiently parsing partially-correct code snippets or code being edited live.
It's an important building block of the highlighter, but it needs more on top to complete the package. It can be used for anything that requires awareness of code structure in an editor.
I wonder if targeting the Tree-sitter ABI directly could be a viable way to write more accurate parsers in an actual programming language while piggybacking on the ecosystem. Could tree-sitter's runtime ABI be adapted for GLL parsers instead of GLR? I haven't looked deep into it yet.
I also had a hard time understanding the context given just the link.
Or... website text editors which historically have had imperfect syntax highlighting.
Notice the Zed sponsorship.
That's the best one sentence description there is and it's at the top of the Github README. I think that would fit nice at the top of https://arborium.bearcove.eu too