Add MATLAB support (.m files) — grammar already exists on PyPI

[catalystdream]

Summary

graphify currently has no MATLAB/tree-sitter support at all — .m files fall through to a bare file-stub node with zero structural edges (no functions, no calls, no cross-file imports/references detected), even though a real, maintained tree-sitter grammar for MATLAB already exists and is installable as a normal dependency.

Evidence

• Checked the installed graphifyy package dependencies (uv tool install graphifyy) — no tree-sitter-matlab among the 27 language grammars bundled.
• A working grammar exists: acristoffers/tree-sitter-matlab — actively maintained (updated within the last ~2 weeks as of filing), and already published on PyPI as tree-sitter-matlab (currently v1.3.0), same packaging convention as graphify's other tree-sitter-<language> dependencies.
• Confirmed the gap concretely on a real corpus: 4 MATLAB files with genuine call/usage relationships (one script calling into another, importing shared config) extracted to 4 isolated nodes, 0 edges via graphify extract. By contrast, a 6-file Python module with equivalent internal structure extracted to 72 nodes, 152 edges in the same session — same tool, same AST-only pass, only the language differed.
• This isn't just "reduced fidelity" — it produces a wrong-by-omission answer for any code-navigation question touching MATLAB. Asked graphify query "what code implements X", where X is a MATLAB-only feature — the correct files never appeared anywhere in a 35-node depth-2 BFS, because they have no edges to be traversed through.

Why it matters

MATLAB is heavily used in engineering/scientific domains (controls, aerospace, signal processing, simulation) where graphify's docs+code+papers pitch is otherwise a great fit — but right now those codebases get effectively no structural graph at all for their primary language.

What I looked at on the implementation side

Per-language extraction in extract.py looks hand-written per language (~150-300 lines each, e.g. the Julia block), not a generic tree-sitter-node walker — so this isn't a one-line pip install fix, it'd need a new extraction function targeting tree-sitter-matlab's specific node-type names (function definitions, classdef blocks, calls, etc.), following the same pattern as the existing per-language blocks. Flagging that context in case it's useful for scoping the work, not assuming it's trivial.

Happy to help test against a real MATLAB corpus if that's useful once there's a WIP branch.

[catalystdream]

Correction/sharpening after digging into the actual source — the diagnosis is more specific than "no MATLAB support," and the fix path is more precedented than I first thought:

.m is not unhandled — it's claimed by Objective-C. detect.py's CODE_EXTENSIONS and extract.py route .m/.mm to extract_objc() via tree_sitter_objc unconditionally. There's no content check for .m specifically.

Feeding real MATLAB source through the Objective-C parser produces a broken parse, not a clean skip. Tested directly against one of the files from my original report:

import tree_sitter_objc as tsobjc
from tree_sitter import Language, Parser
language = Language(tsobjc.language())
parser = Parser(language)
tree = parser.parse(open('rendezvous_dynamics.m', 'rb').read())
print(tree.root_node.has_error)  # True

root.has_error = True, with the top-level children coming back as generic declaration/expression_statement nodes that don't correspond to any real MATLAB semantics — the parser is just doing its best to force MATLAB syntax into a C-family grammar. This is worse than silently skipping the file: it's a genuine risk of extracting garbage nodes/edges from whatever fragments happen to parse as "valid enough" Objective-C, not just missing coverage.

The fix has a direct precedent already in this codebase. extract.py already content-sniffs .h files to route between extract_cpp and extract_objc rather than trusting the extension alone (see the comments around line 12093/12383: "a .h may route to either extract_cpp or extract_objc by content"). The natural fix for .m is the same pattern: content-sniff for Objective-C markers (@interface, @implementation, @end, #import) vs. MATLAB markers (function ... end block structure, %/%{ %} comment style), and route non-Objective-C .m files to a new extract_matlab() built on tree-sitter-matlab (still needs writing, per my original report, but the dispatch half of this is a small, idiomatic addition matching existing code).

Happy to share the two-line repro above against a larger MATLAB sample set if useful for testing the content-sniff heuristic.