Feature Requests: Lua support, and questions of beyond.

[UsingOstensibly]

Lua is my current use primary case with Dirac, but it is not supported in the list of langauges, so its support is degraded compared to others.

It is a fairly popular language and has an active listing: https://github.com/tree-sitter-grammars/tree-sitter-lua

Speaking more broadly, there are a lot of other languages such as Zig (sorta niche), Fennel (very niche), etc. that I'd be interested using with Dirac in the future that have treesitter queries. Including some of my own private DSL queries that I'd like dirac to gain awareness for, but couldn't be expected to be added given they'd be constantly moving targets for a userbase of one. Not sure how those can be easily handled without constantly forking? The pace of AI harnesses are blistering, and Dirac is no different with around daily changes, so maintaining a fork would certainly be a hassle. Ideally there would be some way to point Dirac at some queries stored separately so it doesn't need to be constantly updated.

[UsingOstensibly]

An aside, I got directed here from the About section of Dirac in VS Code, but people seem to be making issues for feature requests?

[dirac-run]

Thanks for opening a discussion! For a more immediate unblock, I believe adding Lua (or any other language support) is not too tricky

1. Create the Query File
   Create a new file src/services/tree-sitter/queries/lua.ts. This file should export the tree-sitter query string for Lua. You'll want to capture definitions and references. I believe you know this already

2. Export the Query
   Add the new query to src/services/tree-sitter/queries/index.ts:

export { default as luaQuery } from "./lua"

3. Register the Language in the Parser
   Update src/services/tree-sitter/languageParser.ts:

4. Import luaQuery from ./queries.

5. Add lua to the switch (ext) block in loadRequiredLanguageParsers:

   case "lua":
       langName = "lua"
       queryText = luaQuery
       break

6. Update the Build Script
   Update esbuild.mjs to include lua in the languages array. This ensures the .wasm file is copied to the dist/ directory during the build process:

const languages = [
    // ... existing languages
    "lua",
]

5. Ensure WASM Availability
   Dirac relies on the tree-sitter-wasms package. Check if tree-sitter-lua.wasm exists in node_modules/tree-sitter-wasms/out/. If it's missing, you may need to update that package or manually provide the WASM file in a location where loadLanguage can find it.

6. Add tests in src/services/tree-sitter/tests/fixtures/lua/

Do you have bandwidth to take this on? Feel free to send a PR. I am a bit swamped rn but can do this in some time

[UsingOstensibly]

Sure, might be a minute. This is the one, right? Lua is thankfully among them: https://www.npmjs.com/package/tree-sitter-wasms

While Fennel is not there, Zig and Bash are. Would follow up PRs for each be welcomed?

I also noticed JSON among them. As tiny and simple as it is, I wonder if Dirac would benefit at all or experience diminishing returns, I might give it a shake for curiosities sake... In contrast, lisps like Fennel, Clojure surely would benefit the most from how models often slip up their deeply nested delimiters, speaking from experience, but tree-sitter-wasms only has emacs lisp.

[dirac-run]

very good points.

1. yes followup PRs are welcome
2. Json is actually quite useful given how common it is

Dirac lazily initializes treesitter parsers so more parsers won't necessarily hurt performance unless there is a project with 10 different languages present and we overload memory loading them all at once, but that's a rare situation so I am not worried