[Feature]: Allow additional filetype->language mappings

[coandco]

Problem or motivation

I have a large PHP codebase where most of the files are of the pattern foo.class.inc. The EXTRA_EXTENSIONS env var allows indexing additional extensions as plaintext, but as far as I can tell there isn't anything that lets you treat an extension as belonging to a particular language.

Proposed solution

The flexible way to do this would be to have some kind of a LANGUAGE_MAP_OVERRIDE env var that lets you map extensions to languages (i.e. something like LANGUAGE_MAP_OVERRIDE=.inc:php,.foo:bar to map .inc to php and .foo to bar). If we don't want to go that route, just adding .inc to the supported PHP extensions would solve my immediate problem.

Alternatives considered

Setting EXTRA_EXTENSIONS currently allows .inc files to be indexed, but loses most of the language-aware benefits of doing so (call graph, semantic chunking, etc).

Area

Indexing

Additional context

No response

Checklist

• I have searched existing issues and this hasn't been requested before

[giancarloerra]

Thanks for the well-scoped request, and you're right that EXTRA_EXTENSIONS only buys plaintext indexing, it loses exactly the language-aware parts (AST chunking, symbols, call graph) you'd want for a real PHP codebase.

I went with your flexible option (the override env var) rather than just adding .inc to PHP globally. .inc is genuinely ambiguous across ecosystems (PHP includes, but also asm/SQL/template includes), so a hardcoded global default would misparse non-PHP .inc files for everyone. The opt-in mapping avoids that while solving your case directly.

It's implemented as EXTENSION_LANGUAGE_MAP (same idea as your LANGUAGE_MAP_OVERRIDE; I named it to parallel EXTRA_EXTENSIONS). For your setup:

EXTENSION_LANGUAGE_MAP=.inc:php

That makes every *.inc file (including foo.class.inc) a first-class PHP file end to end: AST-aware chunking, symbol extraction, and the call graph, not plaintext. It also auto-discovers the extension, so you do not need to also set EXTRA_EXTENSIONS for it. Multiple mappings are comma-separated (.inc:php,.module:php), and it can even override built-ins (e.g. .h:cpp).

A couple of guardrails worth knowing:

• The target must be a language SocratiCode has an AST grammar for (the Full Support languages). Mapping to something it can't parse (e.g. .foo:bar) is ignored, with a one-time warning at startup so it's not silent.
• A mapped extension only changes how that extension is extracted going forward; re-indexing replaces a changed file's chunks/symbols per file, so there's nothing to migrate.

Landed in #79 and ships in the next release. Thanks again for the clear write-up and the repro context.