How code search matches, and where: case, whole words, all the text a regular expression (an editor's toggle; one written `/…/` is anyway), and only `under` a namespace (or that definition).
A named definition's text as its document shows it (current names; `first` is the line its code starts on, after the header), or a page's: what code search reads.
The finder: definitions by name (the letters in order, best matches first), by words in their docs, and, when the query looks like a type (`(xs: T[]) => T`, or anything starting with `:`), by type.
Source as HTML: tokens classed for colouring (k keyword, x control keyword, s string, n number, c comment, f called function, t type name), each reference to a definition a link (`<a data-hash>`), and an import's module a link to its namespace's or package's page. Uses TypeScript's scanner, re-scanning where it needs context: a `}` that resumes a template literal, a `/` that starts a regex.
The links in a page's imports: each name brought in from the codebase to its definition, `#codebase/a/b` to the namespace's page, and a package to its page (at the range the definition uses). Node's builtins aren't pages.
The parts of JSX that highlighting takes from the syntax tree rather than the scanner, by where each starts: text between tags (which the scanner would read as code), closing tags, and tag and attribute names (`aria-label` is one name). A built-in tag (`div`) is coloured as a tag (g), a component as a type (t), linked if it's in `refs`; an attribute name as an attribute (a).
roleOf(cb: Codebase, path: string, hash: string, placement: Placement) => Role
What the definition named `path` is for: a test, a type, a table, a job, an app, or code by where it runs.
Code search, as an editor's find in files: every line of the codebase's definitions (as their documents show them, with current names) and pages that has `query` in it, by definition: its text as written, or a regular expression written `/…/` ([textPattern]), `under` a namespace (or a definition) if it's given. It stops at 500 definitions or 5000 matches: `truncated` says there was more to search.
Every named definition's and page's text, as this branch shows it (its text versions), made again when what it shows changes ([searchTextsKey]). A definition's is its view's: read from the branch's own file when that's there and current, rendered otherwise (a branch only read, `--branch`, has none: never another branch's).
An app's entry point: it runs in the browser, takes no arguments, nothing named calls it, and it isn't a React hook (named `use…`: a library's hooks are called by nothing in its own codebase) (what `tcm dev` is pointed at, like `app.main`).
A function made by `every(...)`: a recurring job. `every` is a definition with the `every` role (`roles`, by hash: codebaseRoles), as the server library's has.
How well `path` matches a name the finder is asked for (`lower`, lower case): the last part exactly (100), the start of it (80), anywhere in the path (60), its letters in order (under 40, less the longer the path), or not at all (0).
What code search's texts are of, as [searchTexts] keeps them: the codebase (one process can serve several: an editor's), the branch and its last history entry (every change to what it shows, text versions included, makes one), and whether documents are read (a session doesn't keep them).
JSX is highlighted as JSX: text between tags isn't code (an apostrophe in it starts no string), tags and attributes have colours of their own, and a component that's a definition is a link.
A definition named as a React hook by every name (`use` and a capital or digit) is one, and so never an app; a component, an entry point, a word that starts with "use", or a definition without a name isn't.
Code search finds text in definitions as they read now (current names), and in pages, by line; a regular expression (written /…/, or all the text with `regex`), whole words and case work as an editor's do; `under` keeps to a namespace or a definition, and it says it stopped early only when there was more to search.