I don't think going all in on treesitter is very practical, considering basic python indentation has not been functional for over a year. I think Helix is a little bit too much of niche layered on niche, and Kakoune is much better all around in my experience.
that sounds hard but I... don't often code in python?
I can see bolting a fallback regex mode for the few languages that have features which ts cannot (yet) accommodate.
And 'niche layered on niche' is -- well, it leaves me wondering how much you've actually used hx. The experience is nominal, the installation is sane, and it was way faster to get to 'genuinely pleasant' than nvim ever was.
As a plus, nix home-manager also handles helix config, which, as a nixos user, puts it over the top for me.
(home-manager also does nvim, but this is mostly mooted by my need for an elaborate (and turing-complete) Packer configuration, which has me using a separate git repo for nvim specifically)
I don't often code in python either, but it's a considerable red flag that one of the largest languages in the world has been completely broken for this long. It makes me not want to invest time building muscle memory for the editor. Sometimes I need to code in python, and when I do, I don't want a lot of inconsistencies and jank.
That's what I mean by niche layered on niche- the editor itself is a niche project that leverages another niche project (tree-sitter) to do indentation, and when contributions on either aren't up to par it kind of falls apart.
I have used the editor a decent amount and it's quite nice when it works. I don't even mind the lack of plugin extensibility because there's not really anything I needed that wasn't built in.
I'd like to point out that the editor is barely a year old and I'm working on it entirely during my free time. It takes time to sort out all the issues and provide excellent support for all languages. I primarily write Rust and Go so those are guaranteed to work well.
It's hard to do tree-sitter query based indentation with space based languages, because the indent has semantic meaning and the AST node is invalid until indentation is typed out. We do have a potential solution (https://github.com/helix-editor/helix/issues/763#issuecommen...), it just needs someone to go and implement it.
I don't consider tree-sitter niche though. Outside of VSCode it's widely adopted, but yes it's probably too soon to only rely on tree-sitter with no fallback. Of course we do implement fallback behaviours too: we try to use tree-sitter first, then provide a simpler fallback for cases where there's no grammar available (or like in this case, it's not a great fit).
So it should be possible in theory to use treesitter data to calculate indents, though it seems difficult.