Written by Claude (Opus 5), an LLM made by Anthropic, posted at andy5995's direction.
The line-based Configuration Editor prints its whole field list in one pass. There are 38 fields, and the title rule, closing rule, * legend, blank line and prompt take about five rows on top of that, so on an 80x25 console the first sixteen fields have scrolled off before the sysop reaches the prompt. The list redraws in full after every edit, so it happens again on each pass.
This is the fallback editor, reached when the tabbed TUI cannot run: a legacy Windows console (#98), redirected stdin, or a TUI that fails to start. On a console that can render ANSI the sysop gets the TUI instead and sees none of this.
Splitting the list across screens fixes it. Two pages of 19 fit a 25-row screen, but with nothing spare. Grouping by topic instead, the way the TUI's tabs already divide the same fields, would leave room and match what a sysop coming from the original expects. The numbers are stable identifiers rather than positions — 28 and 29 already sit outside the printed sequence — so regrouping does not renumber any field.
Whatever the split, the prompt needs a way to move between pages. andy5995 suggested PgUp and PgDn, which is the familiar pairing and is what the original's own editor uses. Two things to settle first:
- The prompt is line-based today: it reads a whole line and waits for Enter, so it never sees a bare keypress. Page keys mean reading raw keys there instead.
- Whether a legacy Windows console delivers PgUp and PgDn as escape sequences is a separate console setting from the output one this fallback already failed on, and I have not checked it. If they do not arrive, the keys would be missing in the one case the fallback exists to serve.
A letter pair at the existing prompt (N and P, say) needs neither change and works everywhere, so it may be worth keeping as the fallback for the fallback even if the page keys land.
What I actually checked: I read the editor's field list and confirmed it has no paging, and andy5995 supplied a screenshot of the fallback editor on a Windows console showing the list beginning at field 17. The row arithmetic above follows from that screenshot rather than from a measured run.
The line-based Configuration Editor prints its whole field list in one pass. There are 38 fields, and the title rule, closing rule,
*legend, blank line and prompt take about five rows on top of that, so on an 80x25 console the first sixteen fields have scrolled off before the sysop reaches the prompt. The list redraws in full after every edit, so it happens again on each pass.This is the fallback editor, reached when the tabbed TUI cannot run: a legacy Windows console (#98), redirected stdin, or a TUI that fails to start. On a console that can render ANSI the sysop gets the TUI instead and sees none of this.
Splitting the list across screens fixes it. Two pages of 19 fit a 25-row screen, but with nothing spare. Grouping by topic instead, the way the TUI's tabs already divide the same fields, would leave room and match what a sysop coming from the original expects. The numbers are stable identifiers rather than positions — 28 and 29 already sit outside the printed sequence — so regrouping does not renumber any field.
Whatever the split, the prompt needs a way to move between pages. andy5995 suggested PgUp and PgDn, which is the familiar pairing and is what the original's own editor uses. Two things to settle first:
A letter pair at the existing prompt (
NandP, say) needs neither change and works everywhere, so it may be worth keeping as the fallback for the fallback even if the page keys land.What I actually checked: I read the editor's field list and confirmed it has no paging, and andy5995 supplied a screenshot of the fallback editor on a Windows console showing the list beginning at field 17. The row arithmetic above follows from that screenshot rather than from a measured run.