Code reference detail
parsing.test.ts
reqlan rq/language/packages/language/test/parsing.test.ts
| Idea | Status | Tags | Summary | Katz |
|---|---|---|---|---|
| import_error_recovery | A malformed import must not invalidate the rest of the file. Recoverable invalid `from` shapes parse as local import nodes with a line-level diagnostic: - `from "path" as alias` ( mistaken namespace form ) — suggest `import "path" as alias` or `from "path" import <idea>` - bare `from "path"` — require the `import <idea>` clause - `from` without a quoted path — consume the remainder of the line as an invalid import Later imports and top-level ideas continue to parse and link normally. Same recovery posture for nameless top-level braces: ["./syntax.rq".no_name_idea_safe_warning]. If lex / parse never completes, see ["./parser_lexer.rq".parse_budget_timeout]. | 0.058 | ||
| import_from | From-import syntax uses from, a quoted path, import, and an idea name. From-import may list more than one idea. Separate the names with commas. From-import may include an alias using as. The parser records a span for the path, each idea name, and each alias. Each of those tokens is its own document link. The path links to the file. An idea name links to that declaration. An alias links to the same declaration. When the alias contains the imported idea name, Ctrl + click on a bracket reference still treats the whole alias as one link. See ["../extension/language/syntax/features-syntax-highlighting.rq".aliased_from_import_ctrl_click]. The language server uses the parser spans: ["../extension/language/support/language-server-rust.rq".language_server_rust]. | 0.220 | ||
| import_keywords | The keywords import, from, and as are reserved for import statements. Import keywords may also appear as ordinary words in idea body text when not at statement start. | 0.047 | ||
| closing_nested_curly_braces | if, for some reason, there is a prose block containing only closing curly braces, they should be escaped and allowed \ } like this. | 0.040 | ||
| context_sensitive_lexer_scaling | done | Context-sensitive token classification for structural / prose braces and top-level import keywords must remain linear in document size. The lexer records brace-depth changes sparsely ( not per-character tables ) and looks them up in log time while tokenising, so workspace language-server initialization and editor re-lexes stay bounded. Code fences are skipped during the brace scan so example braces cannot inflate work or desync depth. Bounded work still assumes the lexer / parser *returns*; unbounded hangs are cut by ["./parser_lexer.rq".parse_budget_timeout]. | 0.097 | |
| fencing_comments | done | A complete same-line fence keeps `//` and `/*` as prose, not comments. Closed double quotes: " / / this line " contains no comment. Closed backticks: `//this line` contains no comment. Closed backticks with a glob: `@reqlan/*` does not open a block comment. An unclosed backtick is not a fence, so this line ` An unclosed quote is not a fence, so as does " The Langium lexer, the Rust lexer, comment scanners, and TextMate must use this rule. Related: ["./syntax.rq".comments], ["./syntax.rq".inline_code], ["./syntax.rq".naked_strings_in_body], ["../core_analysis/rust_port.rq".comment_span_align]. | 0.078 | |
| nested_curly_braces | if there is a prose block containing curly braces, { such as this one } they should be treated as part of the prose. Matching braces that end a line — including adjacent pairs like { { SITE_URL } } — stay in the body; they must not close the enclosing idea. A lone `}` on its own line still closes the structural block so an unbalanced prose `{` cannot swallow the idea closer. | 0.108 | ||
| one_liner_curly_brace_context | this should { be acceptable } as well | 0.050 | ||
| block_idea | A block idea is a name followed by curly braces that contain a body and optional attributes. The opening `{` may share the line with the closing `}` ( `name {}`, `name {hello}` ). The opening `{` may also sit at the end of the name line, with the closer on a later line. `{` starts a block only when it is immediately after the name ( optional spaces ). If other text is between the name and `{`, the line is a [simple_idea] and the braces are body text. The first unstructured text in an idea body is the main description when no other body attribute is marked. | 0.099 | ||
| code_snippets | Idea bodies and block attribute values may embed fenced code blocks delimited by triple backticks. An opening fence is three backticks as the first non-whitespace characters on a line, optionally followed by a language tag such as python or rq. A closing fence is three backticks as the first non-whitespace characters on a line. Three backticks in the middle of a line are prose. They do not open a fence. Everything between the fences is literal opaque text — it is not parsed as reqlan syntax. Keywords, imports, attributes, braces, and quotes inside a fence are inert for the parser and may be shown as examples without parse errors. Fenced blocks may span multiple lines and preserve their inner content verbatim. Brace-depth tracking must skip fence interiors so example braces cannot desync surrounding structure ( [no_name_idea_safe_warning] ). Related: ["../core_analysis/rust_port.rq".comment_span_align]. | 0.113 | ||
| dash-or_undersore_delimited-idea | it should be possible to use dash or underscore delimited idea names. | 0.040 | ||
| file_layout | incomplete | A file begins with zero or more import statements, followed by top-level ideas and ideasets. The file forms an implicit ideaset; its name may default to the filename without the suffix. Front matter syntax is not yet specified. | 0.070 | |
| idea_name | Idea names are identifiers or double-quoted strings. Unquoted names follow identifier rules and may use letters, digits, underscores, and dashes, for example myidea, my_idea, or dash-or_underscore_delimited-idea. Quoted names allow spaces and other characters when wrapped in double quotes. Idea names must be unique within their ideaset or file. An idea, one-liner, and ideaset must not share a name in the same file. Idea names should not use reserved keywords. | 0.063 | ||
| inline_code | done | Single-backtick spans ( `…` ) are opaque `INLINE_CODE`. They may show example syntax such as a quoted path plus idea. The grammar does not parse bracket or file references inside the span. Check and the language server must not report those examples as unresolved ["../reference_types.rq".file_reference] or idea refs. Related: [code_snippets], ["../core_analysis/rust_port.rq".comment_span_align]. | 0.165 | |
| lists | Parenthesized lists contain newline-separated items. Each list item is either a one-liner or a nameless block idea in curly braces. Lists may appear as attribute values and inside block bodies. Named lists use a label followed by a parenthesized item list; the opening parenthesis must be followed by a newline before the first item. Nested lists may appear inside block values or as list items; the opening parenthesis must be followed by a newline before the first item. Inline parentheses in body prose — for example continuous ( " live " ) physics or ( pixelRatio 1, no WebGL ) — are plain text, not lists. | 0.055 | ||
| naked_strings_in_body | Quoted text in idea bodies, attribute values, and list items is plain prose, not a string literal. Quote characters are preserved in the body text. For example, " Fit to view " in a bullet line is body text. String literals are reserved for import paths, top-level quoted idea names, and quoted paths inside bracket references. Quoted path-like body text is not a ["../reference_types.rq".file_reference]: ["../reference_types.rq".reference_edgecase]. | 0.065 | ||
| name_only_ideas_it_should_be_possible_to_use_name_only_ideas_without_a_body | 0.040 | |||
| no_name_idea_safe_warning | done | A top-level nameless curly-brace block — `{... }` with no idea name — must not take down the parser or the language server workspace. Parse the block as a recoverable anonymous top-level element, emit a descriptive warning that a name is required before `{`, and continue so later ideas, imports, and links still work. Nameless blocks inside parenthesized lists remain valid list items per [lists]; only top-level nameless blocks warn. Related recovery posture: ["./imports.rq".import_error_recovery]. Block shape: [block_idea]. Fenced examples must stay opaque per [code_snippets] so braces inside snippets cannot desync structural depth. Non-termination ( lex / parse never finishes ) is a different failure mode: ["./parser_lexer.rq".parse_budget_timeout]. | 0.072 | |
| reference_brackets | Single-bracket references use square brackets around a target. Forms include ideaset-only, idea-only, ideaset dot idea, and idea dot attribute targets. An idea dot attribute target follows [attribute_namespacing]. | 0.263 | ||
| reference_file | References may target arbitrary files, not only. rq files. File reference syntax uses a bracketed quoted path. A relative path resolves from the document directory. When that path climbs with `..` and the file is not there, the same path is tried from each ancestor directory up to the workspace folder. The document-directory file wins when it exists. Line or line-range references append `L#n` or `L#n-m` after the path inside the brackets. Test-name references append `:` and the test title after the path ( for example `./app.test.ts:lists items` ). The first `:` after the path starts the title; later `:` characters stay in the title ( `e2e: …` ). `://` and a Windows drive `C:` / `C:/` are part of the path, not a test suffix. Symbol references append a dot-separated symbol path after the quoted file path. Quoted body text is not a file reference: ["../reference_types.rq".reference_edgecase]. | 0.266 | ||
| reference_wikilink | Double-bracket wikilinks use doubled square brackets around a target. Wikilinks may include an obsidian-style alias pipe with a display label after the target. A bare pipe character in body prose — for example kind: idea | file | selection — is plain text, not wikilink syntax. | 0.230 | ||
| round_brackets | Round brackets indicate a list of ideas or attributes. Items may be separated by commas or newlines. Attribute list values may use commas or newlines; see @ example_list_attribute_using_commas and @ example_list_attribute_using_newlines. Parentheses in body prose — including API call shapes like cytoscape. animate ( { fit, easing: ' ease-out-cubic ' } ) — are plain text, not list syntax. | 0.045 | ||
| simple_idea | A one-liner idea is written as a name followed by unstructured body text on the same line. A name-only idea is a one-liner with just the name and no body text. One-liner ideas do not continue onto subsequent lines. A `{` that is not immediately after the name is body text, not a block opener — see ["./syntax-edge-cases.rq".one_liner_curly_brace_context]. `name {}` and `name {hello}` are [block_idea] forms, not one-liners. | 0.075 | ||
| string_and_reference_apostrophes | strings should use double or single apostrophes interchangeably and support backslash escapes. | 0.040 |
Reference labels
block_idea, closing_nested_curly_braces, code_snippets, context_sensitive_lexer_scaling, dash-or_undersore_delimited-idea, fencing_comments, file_layout, idea_name, import_error_recovery, import_from, import_keywords, inline_code, lists, naked_strings_in_body, name_only_ideas_it_should_be_possible_to_use_name_only_ideas_without_a_body, nested_curly_braces, no_name_idea_safe_warning, one_liner_curly_brace_context, reference_brackets, reference_file, reference_wikilink, round_brackets, simple_idea, string_and_reference_apostrophes