Hi Jonas,
Sorry, I only just noticed your reply because it was sent via the BTS
and did not reach my mail client as expected.
I think I understand your point now: the motivation for splitting is not
reducing coupling, but isolating maintenance and release risks from the
core hx package.
Let me take a closer look at the uwsgi-style ABI approach you mentioned
and see how a split package would look in practice.
Best regards,
Junyong
On Mon, 18 May 2026 14:39:51 +0200 Jonas Smedegaard <[email protected]> wrote:
> Quoting Junyong Liang (2026-05-18 13:56:44)
> > Regarding the TAB separator: I think |IFS=$'\t'| is bash-specific
> > syntax. The current shebang is |/bin/sh|, which resolves to |dash| on
> > Debian systems, so I do not think that form is portable there.
>
> Indeed - good catch!
>
> (in fact, I ran shellcheck on that script, then changed the code and
> tested that it worked, but forgot to run shellcheck on it again, which
> would have revealed my mistake)
>
> > Would something like this make more sense instead?
> >
> > |tab=$(printf '\t') extract_grammars | while IFS="$tab" read -r set
name
> > repo rev; do ... done |
>
> Yes, looks good.
>
> > I did previously experiment with splitting this into an additional
> > source package, but that introduces a synchronization issue: once hx
> > itself updates, the highlight data ideally needs to update in lockstep
> > as well, yet in practice there would inevitably be a delay because the
> > secondary package depends on the hx update landing first.
> >
> > Keeping them in the same source package allows synchronized uploads,
> > which feels more correct to me.
>
> Yes, agreed they are tightly coupled. We can ensure that is upheld by
> having hx provide a virtual package hx-plugin-abi-$HASH and have the
> plugin packages depend on that abi. Examples of doing that, including a
> debhelper script to keep the logic of computing the abi at the hx
> package, is in src:uwsgi - another example is in src:swi-prolog but I
> know less about how that one is implemented (have only been involved in
> using it).
>
> > Additionally, upstream Helix developers explicitly describe these
> > grammars as strongly coupled to the exact Helix revision. In
particular,
> > pascalkuthe wrote here:
> > https://github.com/helix-editor/helix/discussions/12433
> >
> > No we require that the tree sitter grammar matches the exact commit
> > so it doesn't make sense to use anything but the exact commit
> > specified in the config that the queries were created for (which are
> > specific to helix).
> >
> > Tree sitter grammars are not stable and not reusable across
> > different editors/programs.
>
> I see the above not as a separate point but the same point of strong
> coupling.
>
> The reason I prefer separation is not to loosen up the coupling, but to
> insulate the core package from problems with the plugin package which
> in the worst case could cause it to be kicked out of testing during
> freeze. I would prefer having hx without plugins stabilize over having
> hx kicked due to problems in packaging plugins.
>
> > Given that, I still tend to view this as a tightly coupled component
> > rather than a reusable shared asset.
> >
