Skip to content

Add wiki-reader: a +wiki reading front end for @wiki - #1

Closed
HarryCordewener wants to merge 1 commit into
mainfrom
add-wiki-reader
Closed

HarryCordewener wants to merge 1 commit into
mainfrom
add-wiki-reader

Conversation

@HarryCordewener

Copy link
Copy Markdown
Member

Adds wiki-reader as an official package, plus its index.yaml entry.

What it adds over @wiki

+wiki namespace index
+wiki <page> the article, rendered whole
+wiki/list [<ns>][=<page>] paged
+wiki/search <text>[=<page>] paged
+wiki/recent [<n>][=<page>] paged
+wiki/info [<page>] metadata
+wiki/audit staff

Listings are the one place a terminal reader is genuinely stuck — @wiki/list can run to a hundred lines. Those are paged, with a footer printing the exact next command.

Deliberate omissions

Article text is not paged or wrapped. The client does both better; layout control is spent only on chrome and listings.

Nothing is remembered between commands. Paging is an argument rather than a session, so there is no stale reading position and no result numbering that depends on both sides agreeing which listing was last shown. The object therefore writes nothing anywhere and needs no wizard bit — worth noting for a package that installs into the master room.

No /create, /edit, /delete, /publish, /protect wrappers. That is @wiki's job.

/audit is the only staff command, because drafts are invisible to softcode by design — wiki(), wikilist(), wikisearch() and wikirecent() never return an unpublished page, and there is no reader identity to check one against. A softcoded draft queue is impossible, not unbuilt.

Notes for review

  • Uses the RENDERMARKUP templates from SharpMUSH#825, including WIKILINK, so [[Page]] in an article body becomes a clickable +wiki command for Pueblo/WebSocket readers and highlighted prose otherwise. CODEBLOCK and TABLE are left unset so their defaults (syntax highlighting, apportioned column layout) apply.
  • xch_cmd in listings needs the Send_OOB power; without it tagwrap() is refused and references still print as pasteable text, so it degrades rather than breaks.
  • The common-functions dependency points at SharpMUSH/SharpMUSH examples/packages/, because that package is not published in this repo. Publishing it here would be the better long-term fix and would let this dependency point at a sibling.
  • tools/PackageValidator --strict passes: 7 manifests, index consistent.

🤖 Generated with Claude Code

@wiki is complete but browser-shaped. It hands over a whole article at
once, and its listings return references you have to retype. On a 24-line
terminal the listings are the part that actually hurts, so this pages
those and gives them a header and footer saying where you are and how to
get the next page.

Article bodies are emitted whole through rendermarkdowncustom() -- the
client wraps and keeps scrollback better than a server-side pager can,
and wiki(<page>,text) is the markdown flattened, so headings and lists
would be lost without a render.

Nothing is remembered between commands: paging is an argument
(+wiki/list help=2), not a session, so there is no reading position to
go stale and no numbering that depends on both sides agreeing which list
was last shown. Consequently the object writes nothing anywhere and
needs no wizard bit.

Commands are regexp $-commands with named captures, so "=<page>" can
only be a page number and +wiki/search a=b is simply a search for a=b.

Staff get +wiki/audit over published pages. It is deliberately the only
staff command: drafts are invisible to softcode by design -- wiki(),
wikilist(), wikisearch() and wikirecent() never return an unpublished
page and there is no reader to check one against -- so a softcoded draft
queue is impossible rather than merely unbuilt.

Validated with tools/PackageValidator --strict.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Aug 28, 2026

Copy link
Copy Markdown

Warning

Review limit reached

Next included review available in 29 minutes.

View limit details

Limit details: You’ve used all 2 included reviews currently available. Your 56 included PR review attempts over the past 7 days set your current allowance at 2 reviews per hour.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 6de54fe4-f3cb-4b18-8bd1-bf661d2b0dc9

📥 Commits

Reviewing files that changed from the base of the PR and between aac3670 and b240fb7.

📒 Files selected for processing (2)
  • index.yaml
  • wiki-reader/package.yaml

Comment @coderabbitai help to get the list of available commands.

@HarryCordewener

Copy link
Copy Markdown
Member Author

Closing — this belongs in SharpMUSH itself rather than here, and is now open as SharpMUSH/SharpMUSH#829 against examples/packages/. That also puts it next to common-functions, which it depends on and which is not published in this repo, so the dependency resolves without pointing across repositories.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant