Run-time errors for the Strings module, page shortcuts, help add-in 1.1.0, and five defects queued

.github/actions/run-gates/action.yml

@@ -236,6 +236,12 @@ runs:
     - name: Verify the package test markers and projects (check_package_tests.mjs)
       shell: bash
       run: node scripts/check_package_tests.mjs
+    # Every page's Common Errors section is what scripts/errors.mjs write makes of the
+    # run-time error data under errors/, and the data is in order. Sources
+    # only: no twinBASIC, no VB6.
+    - name: Verify the Common Errors sections against their data (check_errors.mjs)
+      shell: bash
+      run: node scripts/check_errors.mjs
     # The symbol index (tB/symbols.json) is read by the IDE help add-in. A
     # build that indexes the reference cleanly says nothing about the rules
     # that did not fire on it, so these probes assert each against the case

WIP.Authoring.md

@@ -138,6 +138,16 @@ and a keyword such as `ElseIf` belongs on a page only when the page explains it.
 
 Relative links resolve against the **rendered URL** (the page's `permalink:`), not the file path. Pages that share a URL folder can use bare names (`[Y](Y)`); crossing folders needs `../` to climb out.
 
+**A page many pages link to can have a shortcut** (owner, 2026-10-21): `shortcut: <Name>` in
+its front matter, and every page links to it as `[x](tb:<Name>)` or `[x](tb:<Name>#anchor)`,
+from any folder, with no `../`. The build (`relativeLinksPlugin` in `builder/render.mjs`)
+writes the page's permalink; the fragment is kept as written, and the link check checks it. A
+name is a word (letters, digits, `_`, `-`, starting with a letter); an unknown name, a name two
+pages claim, and `tb:` as an image's source fail the build. Inside code a `tb:` link is left as
+written. The first is `shortcut: Errors` on `Reference/Run-time-Errors.md`, whose anchors are the
+error numbers themselves: `[5](tb:Errors#5)`. Any page that wants one may have one; a plain
+markdown preview (GitHub, an editor) shows such a link as dead.
+
 The URL prefixes are *not* uniform across packages — VBA pages live one segment shallower than VBRUN pages, so cross-package links are asymmetric:
 
 - Core statement → `/tB/Core/<Symbol>`
@@ -353,6 +363,13 @@ Add a `> [!NOTE]` callout or rewrite the affected section when source diverges.
 
 When in doubt about a tB-specific behavior, check `docs/Features/` and `docs/Reference/index.md` before assuming VBA semantics carry over.
 
+**VBA-Docs content that twinBASIC and VB6 both contradict is commented out, not deleted**
+(owner, 2026-10-21): the documentation is meant to become switchable between VB6, VBA and
+twinBASIC, and the VBA text should not be lost. Put it in an HTML comment that starts
+`<!-- VBA:` and says why it is out, outside any table (a comment line inside a markdown
+table ends the table), and keep `--` out of it. The first are the **vbUseCompareOption** rows
+of InStr and InStrRev, which raise error 5 in both runtimes.
+
 ## Document the product as it is, not as it was
 
 **twinBASIC is in a long beta, so a superseded name is not history --- it is noise.**

WIP.Harness.md

@@ -1182,6 +1182,34 @@ options and the remembered targets exactly as they are. It writes only its scrat
 a gate: it needs Windows and a real registry, and the CI runners are Ubuntu. Run it after
 changing `tb-registry.mjs`.
 
+## Default settings, whatever the user saved
+
+`IDE_FLAGS` stop an IDE writing its settings, and nothing stops it reading them: the IDE reads its
+options, panel layouts, keyboard groups and a few more keys through `hostAppObject.GetIDESetting(key)`
+from the user's registry key, so a font size the owner set in their own IDE showed in every IDE the
+tools started (a help-lane check failed on 14 px against 13 px). `scripts/lib/tb-defaults.mjs` makes
+every IDE `launchIde` starts run with the defaults, in the page only and with no write to the
+registry; `try-help-addin` passes `userSettings: true` and keeps the user's.
+
+The script has to run before `main.js` reads the keys, and `main.htm` commits 0.2 to 0.8 s after the
+IDE's browser process writes `DevToolsActivePort`. So `installDefaultsHook` starts before the IDE does,
+polls that file every 5 ms (`launchIde`'s own poll is at 100 ms and answers too late), connects to the
+browser target, auto-attaches to every target with `waitForDebuggerOnStart`, adds the script to each page
+with `Page.addScriptToEvaluateOnNewDocument` and resumes it. The page is `about:blank` when attached, and
+never navigates twice. The script puts a setter on `window.hostAppObject`, which `main2.js` assigns, and
+wraps the host object: `GetIDESetting` answers `""` for the blanked keys and `"{}"` for `GENERAL` and
+`GENERAL2`, every other call goes through with `this` bound to the real object. The keys it left
+unanswered are the licence's, `LICENCEAGREEMENTV3`, `ALLOWERRORREPORTINGV3`, `PUBLISHER` and `NEWYEAR_*`.
+The recent lists are left alone: `test/ide/recent-projects-copies.test.mjs` needs the IDE's own, and
+`shoot_docs.mjs`'s `PAGE_DEFAULTS` empties them where a picture shows them.
+
+A probe of 50 launches hooked 49. The one miss was a page whose document began before the script was
+added. `attachIde` therefore checks `window.__tbDefaults`, the marker the script sets (it lists the keys
+answered, never their values), and reloads the page once when it is missing: the hook's session still holds
+the script, the reload takes about 40 ms, and the UI and the command-line project come back. A marker still
+missing after that is a harness error, exit 2, since the run would have the user's settings. The hook's
+connection lives as long as the process, so a `tbbuild --keep` IDE is hooked until `tbbuild` ends.
+
 ## A private IDE for every lane
 
 **The compiler loads every DLL in `<install>\addins\win32` or `\win64` as it starts.** A

WIP.HelpAddin.md

@@ -1198,6 +1198,12 @@ not: a restart saves a harness about a second against opening a new IDE.
      caption (no read-back of the DWM attribute), Alt+F4, the registry read, maximizing on
      a monitor other than the primary one (the lab machine has one), and the move
      itself, whose loop needs the real mouse, which the harness's desktop has none of.
+     **The window's text is in the IDE's font size** (owner, 2026-10-20): `fontsize.js`,
+     put into the page by `BuildPane`, sends `--ide-fontsize` to the hidden `helpFont`
+     element now and whenever a `MutationObserver` sees the root's style change, and the
+     add-in puts `:root{--ideFontSize:...}` before the theme's rule in the `theme:` message,
+     which `shell.css` sets the body in. The help lane checks the window's size against the
+     IDE page's.
 8. **Settings**, tested by the `help` and `help-offline` lanes on BETA 1007 (owner's
    choice): a gear at the right end of the pane's bar, and on the detached
    window's title bar (in its bar under the Windows caption), opens a drop-down panel of
@@ -1233,6 +1239,49 @@ not: a restart saves a harness about a second against opening a new IDE.
     IDE. **Not done:** the DLLs themselves, built in CI --- the owner's plan is
     to build them there with everything else, once the compiler runs on Linux there.
     Why the pack is made the way it is: [WIP.Build.md](WIP.Build.md#the-help-add-ins-project-file).
+11. **Every add-in's `{ctrl}` and `{alt}` shortcuts fire** (owner, 2026-10-20), tested by the
+    lane `keys-help` on BETA 1010: [keys.test.mjs](test/addin/keys.test.mjs) with the help
+    add-in loaded beside the keys probe. `BuildPane` puts `Resources/SCRIPTS/addinkeys.js`
+    into the page through a hidden element, as hover help does. It puts in capture-phase
+    `keydown` and `keyup` listeners on `window`, which run before the IDE's own: they record a
+    press made with Ctrl or Alt (not AltGr), and on its key-up, within 500 ms, run
+    `addinKeys` for it with the modifiers held at the key-down. They also delete the IDE's
+    `realKeyPresses` record of the key, which is from an earlier plain press, so the key-up
+    does not also run as the plain key (the bug's second half, and the IDE's own key-up
+    bindings, which it never runs for a modified key). The script goes in only while
+    `globalKeyDown`'s text still has the guard (see [Keyboard shortcuts](#keyboard-shortcuts)),
+    so a build that fixes the bug is left alone; a second run replaces the first one's
+    listeners. The IDE's key-down bindings still run beside an add-in's shortcut: Ctrl+-
+    is `tbEditor_DecreaseFontSize` as well. A settings-panel row, on by default and kept with
+    `SaveSetting` (`Fixes`, `AddinKeys`), turns it off: the script has a `$ON$` switch as
+    `hoverhelp.js` has and runs again at each change, taking the listeners out when off. The
+    window's panel has its own box, in step through `addinkeys:<1|0>` both ways.
+12. **Ctrl+F in the configuration editors** (owner, 2026-10-21). Manage Keyboard Shortcuts
+    and Manage Panel Layouts (`showConfigEditor`) edit each entry in a plain
+    `textarea.genericMonospaceTextArea`, made again whenever another entry is picked, not
+    in Monaco, so there is no find widget to switch on; and `globalKeyDown` returns before
+    the keymap while a modal dialog is open. `Resources/SCRIPTS/textfind.js`, put in by
+    `BuildPane`, adds a capture-phase `keydown` listener on `window`: Ctrl+F in such a text
+    area puts a find box over it (positioned in the text area's parent), Enter and F3 select
+    the next match, Shift with either the one before, round past the end and in any case,
+    and Esc closes the box (the Visual Studio keys: F3 and Shift+F3 work with the box closed,
+    on the last query, and open the box when there is none; Ctrl+F3 and Ctrl+Shift+F3 take
+    the one-line selection, else the word at the caret (letters, digits, `_`), as the query
+    and search without the box). A match is scrolled to by measuring it in an off-screen
+    mirror of the text area (`matchRect`), a third down and clear of the box;
+    `window.tbDocsTextFind.visible(area)` tells the test whether the selection shows. Each handled key is stopped at `window`, so the dialog's own
+    Escape handler (which would close it unless the focus is in a text field) never sees it.
+    Focusing the text area does not reliably scroll it to the caret. A second
+    settings-panel row (`Fixes`, `TextFind`, on by default) turns it off, by the same
+    `$ON$` switch, and the window's box follows through `textfind:<1|0>`.
+
+    **Zoom, not done** (owner, 2026-10-20: the IDE's own Ctrl+/Ctrl- and Ctrl+Alt+/Ctrl+Alt-
+    font commands are enough for now). WebView2's own zoom is off in the IDE and no host call
+    reaches the main WebView2's zoom; CSS `zoom` on the page leaves Monaco at its old width
+    and puts context menus and hovers at the pointer's position times the zoom; the font
+    options scale text but not icons or controls. Emulated device scaling (what a WebView2
+    `ZoomFactor` does) was right throughout, so whole-IDE zoom needs that host call
+    upstream. The probe and pictures are in `.claude/tooling-review-scratch/zoom/`.
 
 **Lookup:**
 
@@ -1325,3 +1374,9 @@ The rules for testing add-ins bind every session and are in
 add-in in the real install's `addins\` or in `%APPDATA%\twinBASIC\addins\`, no real browser
 from a test, every `SaveSetting` application named in `lanes.mjs`, IDEs ended by pid, and
 one project per IDE.
+
+**A change a user of the add-in would notice gets an entry in `add-in/CHANGELOG.md` and a
+new version** (owner, 2026-10-20), in the same commit: `project.versionMajor`, `Minor`,
+`Build` and `Revision` in `add-in/Settings`, with `versionAutoIncrement` left `None`, so
+that a lane's or a reader's build changes nothing. The changelog lists the add-in's own
+behaviour, not the documentation or the symbol index it carries.