Reposting previously private discussion to the bug thread. Hi Jonas,
I have tested and verified the syntax highlighting for Rust and Python, and I can confirm that it works well in my environment. I propose that we define the scope for the core package first. Based on common development needs, I suggest including: C, C++, Python, Rust, Shell, Make, JSON, TOML, and Markdown. These languages cover the majority of my current development workflow. I look forward to hearing your opinion on this proposed list. Best regards, Junyong Liang On Thu, Apr 30, 2026 at 1:54 PM Smart SangGe <[email protected]> wrote: > Hi Jonas, > > I have tested and verified the syntax highlighting for Rust and Python, > and I can confirm that it works well in my environment. > > I propose that we define the scope for the core package first. Based on > common development needs, I suggest including: C, C++, Python, Rust, Shell, > Make, JSON, TOML, and Markdown. These languages cover the majority of my > current development workflow. > > I look forward to hearing your opinion on this proposed list. > > Best regards, > > Junyong Liang > > > On Tue, Apr 28, 2026, 16:44 Smart SangGe <[email protected]> wrote: > >> Hi Jonas, >> >> I’m working on a hx-highlight-core package covering popular languages >> like Rust, Python, and Shell. To ensure compliance with Debian’s offline >> build requirements and Helix's specific version needs, I’m using the >> following two-phase approach: >> >> 1. Source Preparation: A script parses languages.toml for exact commit >> hashes, fetches the corresponding Tree-sitter sources, and aggregates them >> into a single, reproducible .orig.tar.xz tarball. >> 2. Build Phase: Using the debian/rules, the build compiles these local >> sources into .so files using a standard C compiler and installs them to a >> global directory, requiring no network access. >> >> This workflow maintains determinism while fulfilling the requirement for >> specific grammar snapshots. Does this approach align with your expectations >> and Debian packaging standards? >> >> Best regards, >> Junyong Liang >> >> >> On Sat, Apr 25, 2026 at 4:34 PM Jonas Smedegaard <[email protected]> wrote: >> >>> Quoting Smart SangGe (2026-04-25 08:24:34) >>> > Hi Jonas, >>> > >>> > I’ve looked into the documentation and source code of both Helix and >>> > Tree-sitter, and I must admit the situation is indeed challenging. >>> > >>> > One observation: the existing tree-sitter-*-src packages in stable >>> appear >>> > to be locked to specific version tags rather than individual commits. >>> This >>> > might cause some friction since Helix often tracks very specific (and >>> > newer) snapshots of grammar repositories. >>> > >>> > I’m still interested in improving this. If you have a preferred >>> > strategy—whether it’s grouping popular grammars into a single source >>> > package or pushing for more individual grammar packages—please let me >>> know. >>> > I’d be happy to assist with the packaging work to help move this >>> forward. >>> >>> Thanks for your interest in solving this, SangGe. You are very welcome >>> to join me in the maintenance of helix. >>> >>> As I see it, there a several challenges here. I have tried to describe >>> some of that already in earlier posts to this bugreport, so please read >>> also earlier posts :-) >>> >>> I would prefer that helix plugins are packaged as separate source >>> packages independently from helix itself. Reason for that is that I >>> would prefer that the potential instability for supporting some fringe >>> language would not affect the stability of helix itself or of support >>> for other languages. That would probably require the src:hx package to >>> provide a binary package hx-dev containing needed source files for such >>> plugin source packages to build from. >>> >>> It makes sense to me to bundle plugins together. If possible to >>> identify reasonably reliable, then I think the ideal would be to bundle >>> source packages by stability and binary packages by runtime relations - >>> e.g. having src:hx-plugins-core providing hx-plugins-shell (for bash >>> and dotfiles and other common "core" formats) and hx-plugins-python >>> (for python3 and python-related formats) and hx-plugins-c (for C and >>> cpp related classic formats) etc., and src:hx-plugins-extra providing >>> various sets of less common format plugins. >>> >>> I don't mind bundling Rust crates - please see the source code for how >>> I already do that for tree-house. And please do ask, if you cannot >>> understand how that embedding is established using git-buildpackage and >>> watch file and copyright file. >>> >>> Kind regards, >>> >>> - Jonas >>> >>> -- >>> * Jonas Smedegaard - idealist & Internet-arkitekt >>> * Tlf.: +45 40843136 Website: http://dr.jones.dk/ >>> * Sponsorship: https://ko-fi.com/drjones >>> >>> [x] quote me freely [ ] ask before reusing [ ] keep private >>> >>
