LineLoom registers the VS Code inline-completion provider for eighteen language IDs (nine enabled by default):
| VS Code ID | Language | Typical extensions | Preview status |
|---|---|---|---|
python |
Python | .py, .pyi |
Initial |
javascript |
JavaScript (including JSX) | .js, .jsx, .mjs, .cjs |
Initial |
typescript |
TypeScript (including TSX) | .ts, .tsx, .mts, .cts |
Initial |
rust |
Rust | .rs |
Initial |
kotlin |
Kotlin | .kt, .kts |
Initial |
go |
Go | .go |
Experimental in v0.4.0 |
java |
Java | .java |
Experimental in v0.4.0 |
c |
C | .c, some .h |
Experimental in v0.4.0 |
cpp |
C++ | .cpp, .cc, .cxx, .hpp |
Experimental in v0.4.0 |
html |
HTML | .html, .htm |
New experimental, opt-in only |
css |
CSS | .css |
New experimental, opt-in only |
lua |
Lua | .lua |
Experimental, opt-in only; editor language mode may require an extension |
cuda-cpp |
CUDA C++ | .cu, .cuh |
Experimental, opt-in only; editor mode provided by VS Code or a CUDA extension |
csharp |
C# | .cs, .csx |
Experimental, opt-in only; C# language mode required |
swift |
Swift | .swift |
Experimental, opt-in only; Swift editor language mode required |
dart |
Dart | .dart |
Experimental, opt-in only; Dart editor language mode required |
ruby |
Ruby | .rb, .rake, .gemspec |
Experimental, opt-in only |
php |
PHP | .php, .phtml |
Experimental, opt-in only |
Actual support uses the language mode reported by VS Code, not the filename alone. For example, .h files may be recognized as either C or C++ depending on the selected editor mode. If needed, use Change Language Mode in VS Code.
Open Command Palette → LineLoom: Manage Autocomplete Languages, check the languages you want, and confirm. This updates the global lineloom.enabledLanguages setting. You can alternatively edit the setting as an array of known IDs:
"lineloom.enabledLanguages": ["python", "typescript", "rust", "go"]The existing nine defaults are unchanged. To try an experimental language, select it in Manage Autocomplete Languages or add its exact VS Code language ID to the setting. This includes "html", "css", "lua", "cuda-cpp", "csharp", "swift", "dart", "ruby" and "php". In an editor without a Lua language extension, first install a trusted language-mode provider or set the correct VS Code language mode. This is development source only until reviewed and released; real-model quality and physical editor accessibility have not yet been tested. The first-party LineLoom Code model track still targets only Rust, C, C++, Python and TypeScript.
Removing an ID turns off LineLoom's model requests for that language. Choosing no languages disables all model-backed inline completions, including manual ones. To restore the defaults, reset the setting in VS Code Settings. JSX uses the javascript selection and TSX uses the typescript selection.
These four additional modes are disabled by default. Enable them individually with
LineLoom: Manage Autocomplete Languages or an explicit value in
lineloom.enabledLanguages. The editor must actually report the matching
language ID (swift, dart, ruby or php); file extensions alone do
not enable suggestions. A language extension may be needed to supply a mode.
Each language can use its own installed Ollama model via
lineloom.languageModels.<language-id>. Adding a model override does not
enable the language or download a model. The existing nine defaults, workspace
trust, ignore/excluded paths, remote-endpoint consent, source window bounds and
selected-related-file opt-in remain unchanged.
Generic instruction-mode prompts receive fixed language guidance:
Swift optionals/value semantics/actors, Dart null safety and Futures/Streams,
Ruby blocks and end delimiters, and PHP namespaces/types/opening tags.
Native FIM prompts still preserve the approved prefix and suffix byte-for-byte.
The output filter recognizes these languages' explicit code-fence labels,
including the rb Ruby alias, and rejects known mismatched language fences.
Limitations: This is source registration and output-format handling, not a new compiler or language server, a syntax validator, a verified improvement in generated-code quality, or new LineLoom Code weights. No Ruby, PHP, Swift, Dart or Flutter SDK is bundled or run. Real editor, accessibility and model-quality acceptance remain NOT RUN. The first-party LineLoom Code research target remains Rust, C, C++, Python and TypeScript.
The C# manual acceptance checklist separates editor-host mock coverage from required physical C#/Ollama, keyboard, accessibility and operating-system verification. Automated tests cannot establish C# code quality.
LineLoom now recognizes VS Code's csharp language ID for .cs and
.csx editors. This experimental mode is disabled by default. To
enable it, select C# under LineLoom: Manage Autocomplete Languages
or include "csharp" in lineloom.enabledLanguages. A .cs filename
alone is insufficient: VS Code must report its editor language as
csharp, and all existing workspace-trust, file-privacy and endpoint
approval checks still apply.
C# has an independent optional Ollama model override through
lineloom.languageModels.csharp; no C/C++ or Java override is silently
reused. Generic instruction-mode prompts use only fixed guidance on
nullable references, using, async/await, generics, exceptions and
existing .NET API contracts. The output filter understands explicit
csharp, cs and c# Markdown fences and rejects recognized C,
C++, Python and other incompatible language fences. Unlabeled output
retains the existing behavior. Native FIM inference still supplies
the previously approved prefix/suffix unchanged.
This does not install the C#/.NET SDK, a VS Code language service, an Ollama model or trained LineLoom Code weights. It does not compile, type-check or execute model-generated code, and real local-model C# quality and physical-editor/accessibility checks remain NOT RUN. The first-party model research target remains Rust, C, C++, Python and TypeScript; C# registration does not silently expand that model's training or quality claims. Selected related-file context remains separately opt-in under its existing allowlist.
The new CUDA C++ language selection is registered as cuda-cpp,
matching the VS Code language mode used by the built-in CUDA C++ grammar
for .cu and .cuh. Some optional language extensions identify CUDA files
as cuda, which is also recognized by the inline provider and mapped to
the same cuda-cpp settings/model selection. Language detection is based
on the actual editor mode, never just a filename or guessed source.
CUDA remains disabled by default, and enabling it does not install a
compiler, GPU toolkit or new Ollama model. Opt in through LineLoom:
Manage Autocomplete Languages or add "cuda-cpp" to the existing
lineloom.enabledLanguages array. You may optionally assign an installed
local model using LineLoom: Assign Language Model; cuda-cpp is the
canonical override key, even for a document reporting mode cuda.
A cpp model override does not silently carry over to CUDA.
For generic local instruction-mode models, CUDA receives conservative
guidance on host/device qualifiers, kernel launches, bounds checks, thread
indexing, memory spaces and synchronization. Existing fixed C++ lexical
hints are used without interpolating identifiers or source text into those
hints. Explicit native FIM models still receive byte-identical prefix
and suffix. CUDA fences (cuda, cuda-cpp, cu) are recognized for
CUDA editors; ordinary C and C++ code fences are allowed in CUDA editors,
but CUDA-only fences are rejected in ordinary C/C++ editors.
This is a source-level language support milestone, not evidence of a real model's CUDA accuracy, CUDA compile correctness, GPU behavior or physical editor acceptance. No CUDA compiler, CUDA runtime, SDK, GPU drivers or model weights are bundled, and CUDA generated code is not compiled or executed by LineLoom. Explicitly selected related-file context still follows its separate narrow source-file allowlist and privacy gates; this change does not expand that allowlist. Standard workspace trust, ignore-file, remote endpoint consent, cancellation and file policy rules remain in effect.
For generic local Ollama models, the Rust prompt builder recognizes common
constructs such as match arms, borrowing, async closures, generic capture
bounds, conditional let-chains, explicit unsafe extern blocks, and
Rust 2024 #[unsafe(no_mangle)], #[unsafe(export_name = "...")], and
#[unsafe(link_section = "...")] attributes. It adds only fixed,
bounded guidance after masking comments and string contents; it does not
compile, type-check or rewrite source code.
Explicitly selected native-FIM models still receive the original prefix/suffix without these added instructions. This is a heuristic completion aid, not a claim of Rust edition compatibility, verified generated-code correctness or a trained LineLoom Code model.
Generic local Ollama models now receive fixed, bounded C and C++ syntax guidance inferred from the already-approved editor prefix. For C this covers allocations/pointers, struct/union/enum declarations, function pointers and preprocessor directives. For C++ it covers templates and constraints, RAII/move semantics, lambdas, constexpr/noexcept and coroutines. The two language modes remain distinct: C-only guidance does not suggest C++ features, and C++ guidance does not assume a specific language-standard version.
The lexical scanner masks comments, character/string literals and C++ raw-string payloads, and interprets backslash-newline continuations before comment detection. It returns only allowlisted instruction text, never filenames, identifiers or source snippets. It scans a bounded prefix and is not a parser, type checker or guarantee of code correctness; a source window beginning inside an earlier multiline comment/literal can be misclassified. The model must still respect existing visible code.
As with Rust, native FIM-capable Ollama tags receive their original prefix and suffix without additional instructions, including for C and C++. No weights, model downloads, editor source collection, new endpoint permissions or release are added by this change.
Source content and explicitly user-selected related files are data, not
instructions. In generic Ollama instruction prompts, LineLoom now prefixes
every source line with | and explains that this marker is not code.
This prevents raw source lines such as </before>, </reference>, or
Completion: from being formatted as new top-level prompt sections.
CRLF/CR line endings are normalized for display; additional visual line
separator characters are shown as escaped Unicode code points so they
cannot create unquoted prompt lines. The source is not rewritten in the
editor, and only the already-approved bounded source is included.
This is structural prompt-framing hardening, not a prompt-injection guarantee: an instruction-following model can still misunderstand or act on malicious comments. Outputs remain untrusted and require developer review. Native FIM model requests without selected references still send the exact original prefix/suffix, without any line prefixes or rewriting.
The separate developer synthetic evaluation harness uses its own versioned instruction protocol; its synthetic scores are not evidence that this editor-specific framing improves real model completion quality. Re-run controlled local/editor tests before making quality claims.
Language registration is not a guarantee that any particular installed Ollama model can generate useful completions. Choose an appropriately licensed coding model and review all generated code. LineLoom still checks workspace trust, file exclusions and nested ignore rules before sending context to the configured endpoint. Remote endpoints require separate HTTPS approval. No AI model weights are included or installed automatically.
Generic local instruction-mode models receive up to four fixed, language-specific
hints inferred from the already-approved bounded prefix. Python guidance covers
async, typing, exceptions, context managers, match/case and decorators.
The developer-only Python f-string scanner now recognizes executable
replacement expressions in f/F, fr and rf strings, while masking
literal text, doubled braces and format specifications. Nested f-strings,
strings, comments and nested braces are handled conservatively. This remains
a bounded lexical heuristic, not Python parsing or a guarantee that
complex format specifications, lambda expressions or generated completions
are semantically correct.
JavaScript covers modules, Promise/async, functions and exceptions; TypeScript
also covers interfaces and types. The scanner masks comments, ordinary and
triple-quoted strings, JavaScript templates, and common regexp literals.
Hints use only fixed text: no identifiers, filenames, paths or snippets are copied into the hints themselves. No workspace scan, new source reads, model downloads, network calls, training or persistent index is introduced. This is a 30,000-character best-effort lexical heuristic, not a parser or a proof of syntax correctness. If the bounded window starts inside a previously opened literal, its inferred state can be wrong. Native FIM models still receive the byte-exact approved prefix and suffix when no related file has been selected. Real local-model quality and physical editor QA remain unverified. Publisher migration and any additional release are postponed.
The local instruction-mode lexical scanner now recognizes regex literals at
expression starts immediately after arrow-function (=>) and logical
(||, &&) operators. Their contents are masked before choosing
allowlisted autocomplete hints, so text resembling async function or
interface inside regex patterns does not become fabricated syntax
context. Escaped slashes inside a regex remain literal content; ordinary
division after these operators is still scanned as source.
This is bounded best-effort lexical recognition, not a JavaScript/TypeScript parser or proof of generated-code correctness. It does not alter the native FIM prefix/suffix, read files, change Ollama endpoints, publish weights or imply improved real-model results. Physical editor and model QA remain needed.
Generic local models sometimes return a Markdown code block tagged for a different programming language. LineLoom now checks the explicit fence label against VS Code's active language mode. Known mismatches, including other language-family fences, are rejected before they become ghost text. Common aliases are supported. JavaScript snippets may be used in TypeScript editors, and ordinary C snippets in C++ editors, but not conversely.
Plain source, unlabeled code fences, and unknown/custom labels retain the previous behavior. This is a conservative formatting quality gate, not a syntax or compiler check. The feature adds no new endpoint calls, file reads, persistent telemetry or source indexing; native FIM prompts and user privacy controls are unchanged. Publisher migration and new releases remain paused.