Proposal: add BSL (1C Enterprise) language support

[Alex1980Alex]

Summary

BSL is the programming language of 1C:Enterprise and OneScript — a business-app platform used heavily across the post-Soviet region and Europe. This proposal wraps https://github.com/1c-syntax/bsl-language-server (403⭐, MIT, Java 17) as a new Language adapter in multilspy.

Motivation

• BSL codebases routinely exceed 2 000 modules; ERP configurations reach 10 000+.
• No LSP-based BSL tooling exists in the Python ecosystem today.
• We are building an LLM-driven refactoring orchestrator on top of multilspy, currently via a private fork using internal APIs.
• Upstream adoption lets downstream tools depend on multilspy>=X.Y instead of maintaining forks.
• Opens BSL to multilspy's existing semantic-tooling ecosystem (Serena et al.).

Evidence (from our internal integration, 2026-04)

Metric	Value
Real-client soak test	2 027 .bsl files opened in 12.93 s, RSS 52 → 201 MB
BSL LS cold start	~8 s
Adapter integration tests	3/3 passing (document_symbols, references, rename)
Grammar error rate	0.0% (complementary fix in a parallel tree-sitter-bsl PR)

Scope

Minimal additive change, matching the eclipse_jdtls / kotlin_language_server pattern.

• `Language.BSL = "bsl"` added to multilspy_config.py.
• Factory branch added to language_server.py.
• New package language_servers/bsl_language_server/ with 4 files:
  • bsl_language_server.py — subclasses LanguageServer, launches java -jar bsl-language-server.jar --lsp as an argv list.
  • runtime_dependencies.json — pins BSL LS 0.22.0 with verified SHA256, downloads from GitHub releases on first use.
  • initialize_params.json — BSL-specific capabilities.
  • __init__.py.
• Three integration tests in tests/multilspy/test_multilspy_bsl.py, skipped when java is not on PATH.
• .gitignore entry for bsl_language_server/static/ (matches other JAR-based adapters).

No changes to core / protocol / other adapters. Python-only, no C extensions, no new runtime deps.

Non-goals

• `workspace/didChangeWorkspaceFolders` eager indexing — tracked separately upstream at 1c-syntax/bsl-language-server. Current adapter uses per-document didOpen, same as Java / Kotlin.
• Diagnostics / code actions — `window/logMessage` and `publishDiagnostics` acknowledged but not surfaced.

Prerequisites

• Java 17+ on PATH (BSL LS is a Spring Boot app built for JDK 17).
• First run downloads ~94 MB JAR; subsequent runs read from static/<version>/.

Next step

If the proposal is acceptable in principle, I have a ready branch on my fork (Alex1980Alex/multilspy:feat/bsl-language, 2 commits, +387/−2 lines) and will open a PR linked to this issue. Happy to iterate on scope before the PR is opened.

[Alex1980Alex]

Update with full benchmark numbers (run full-1d, 2026-04-19):

• 20-task refactor dataset, 5 categories: multilspy 85% (17/20), ast-grep 95% (19/20), combined 90% (36/40).
• Per-category:
  • CAT-1 local variable: multilspy 75%, ast-grep 100%
  • CAT-2 module-local proc: both 100%
  • CAT-3 cross-file export: both 100% (with bulk-didOpen preload on workspace of 2 185 .bsl files)
  • CAT-4 form handler: both 100%
  • CAT-5 edge case: multilspy 50%, ast-grep 75%

The adapter hits 100% on the important cross-file scenarios using bulk-didOpen preload (no dependency on workspace/didChangeWorkspaceFolders), so the per-document indexing limitation of the underlying BSL Language Server is not a blocker in practice.

Happy to run additional scenarios if useful.

[Alex1980Alex]

Stricter metric correction: the previous comment used `applied = bool(edits)`, which credits a backend for returning any edits. After switching the benchmark to `edits_match_expected` (actual edited-file set == ground-truth set), the picture changes significantly:

• multilspy: 55% (11/20)
• ast-grep (text-based baseline): 15% (3/20)
• Per-category for multilspy:
  • CAT-1 local variable: 100%
  • CAT-2 module-local proc: 100%
  • CAT-3 cross-file export: 25% — ground-truth `expected_files` likely incomplete for cross-file scenarios (separate task quality issue)
  • CAT-4 form handler: 0% — same ground-truth gap (form XML + module cross-file)
  • CAT-5 edge case: 50%

Multilspy significantly outperforms the text-based baseline when correctness (edited-file set matches ground truth) is required. The earlier 85%/95% numbers conflated "produced any edits" with "produced the correct edits" — LSP-based rename respects scope, so it edits fewer (but correct) files; text-based rename over-matches across files. On CAT-1/CAT-2 (where ground truth is tight) multilspy is perfect.