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. > > Also, splitting the package would not really solve the total source size > issue itself. Even if users prefer building from source, I think it > would still make sense to split out the extra assets separately if needed. The size issue really is a maintenance issue: Currently I sift through upstream git commits and sometimes cherry-pick some changes. If at each new upstream import there is a potentially big dump of undocumented changes, that disrupts the ability to downstream-curate code that is upstream-curated. - 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
signature.asc
Description: signature
