Mps Aspect Textgen

MPS TextGen Aspect

Loading companion skills

Companion names in this skill are lazy dependencies: load only those relevant to the current task. If this skill came from an MCP server, use the host's skill loader to resolve the companion's unique discovered entry URI on the same host-assigned originating server. If the host has no server-backed skill loader, stop and report that limitation; do not silently fall back to a filesystem copy. If this skill came from a filesystem catalog, load the named sibling from that same catalog at <skills-root>/<skill-name>/SKILL.md, even if remote skill loaders are also available. Do not invent a tool name or server endpoint.

TextGen turns a model (usually the output of generation) into plain text files. It is how BaseLanguage becomes .java on disk, and how any text-targeting language serialises its models. Lives in <lang>/languageModels/textGen.mps, language jetbrains.mps.lang.textGen. Rule bodies are BaseLanguage + smodel + textgen-specific statements (append, indent buffer, with indent).

Prerequisite for any insert: the textGen model must exist (mps_mcp_create_model with moduleName: "<lang>" and modelName: "<lang>.textGen" — aspect ID textGen, case-sensitive, no @ suffix; see aspect-model-stereotypes.md) and must import jetbrains.mps.lang.textGen, jetbrains.mps.baseLanguage, and jetbrains.mps.lang.smodel as used languages before the first mps_mcp_insert_root_node_from_json. Missing any of these three causes node inserts to fail with unresolved-concept errors. See step 1 of the Common-Path Workflow.

Critical Directives

• One ConceptTextGenDeclaration root per concept you want to serialise. Only the file-generating root concept needs extension / filename / encoding; structural concepts inside the file need only textGenBlock.
• extension is a function body returning a string, not a literal property. It must return a string.
• TextGen dispatch is concept-exact, not polymorphic. An extending concept that wants the parent's serialisation must declare its own ConceptTextGenDeclaration (even an empty one) — or its output will be silently missing. See references/dispatch-and-base-component.md.
• The indentation buffer is a per-output-file depth counter. with indent / increase depth / decrease depth and the withIndent flag on NodeAppendPart only mutate the counter — whitespace is emitted only when indent buffer is called. Always pair append \n ; with indent buffer ; on the next line that should be indented. See references/indentation-model.md.
• Prefer with indent { ... } over paired increase depth ; … ; decrease depth ; — the block form cannot leak depth on an early return or exception. Use the paired form only when the scope is not a block.
• Use TextGen only when the final artifact is text. If your pipeline ends in a model-to-model transformation targeting another MPS language (e.g. BaseLanguage), you don't need TextGen — that language's own TextGen handles the final step.
• BinaryWriteOperation (write) cannot be mixed with text appends in the same ConceptTextGenDeclaration. A rule emits either text or bytes, not both.
• The older $ref{node.reference<target>} syntax is deprecated. Use a NodeAppendPart over a resolved node (or over .name).
• Edit textGen models through MPS MCP tools (mps_mcp_insert_root_node_from_json, mps_mcp_update_node). Do not hand-edit .mps files.
• After edits run mps_mcp_check_root_node_problems and rebuild the language; regenerate consumers.

Common-Path Workflow

1. Create a textGen model (mps_mcp_create_model with moduleName: "<lang>" and modelName: "<lang>.textGen"; aspect ID is textGen — case-sensitive, no @ suffix) if absent, then before any insert add the three required used languages: jetbrains.mps.lang.textGen (for ConceptTextGenDeclaration, AppendOperation, parts, NodeParameter, etc.), jetbrains.mps.baseLanguage (for StatementList, DotExpression, control flow, returns), and jetbrains.mps.lang.smodel (for SPropertyAccess, SLinkAccess, SLinkListAccess used to read node data). Also add the structure language whose concepts you serialise (referenced by conceptDeclaration and inside smodel accesses), and jetbrains.mps.baseLanguage.collections if you use maps/lists. Skipping any of the three core languages causes mps_mcp_insert_root_node_from_json to fail with unresolved-concept errors — don't add them piecemeal after a failure.
2. For each concept to serialise, insert a ConceptTextGenDeclaration root via mps_mcp_insert_root_node_from_json. The file-generating concept also needs extension, optionally encoding / filename / filePath / layout / contextObjects.
3. Fill the textGenBlock body — a StatementList of appends, indent buffer, with indent { ... }, and standard BaseLanguage control flow. See references/statements-and-appends.md for the part vocabulary and references/json-blueprints.md for AST shapes.
4. Push formatting heuristics ("should this go on a new line?") into the behavior aspect and call them back from textgen (node.hasNewLineAfter() pattern). See references/delegating-to-behavior.md.
5. For large-file languages (imports area, headers, shared state), declare a TextUnitLayout, a UnitContextDeclaration in the base LanguageTextGenDeclaration, and per-concept UnitContextObjects. See references/layout-and-context-objects.md.
6. Validate with mps_mcp_check_root_node_problems, rebuild the language module, regenerate any consumer, and inspect the produced text.