Add HelpTopic inventory type for non-command help entries

[gfnord]

Context

PR #129 is implementing the HELP command and identified an open question: command docs (extracted from doc comments by the command_handler macro) cover command-specific topics, but there is no place to register help text for concepts — channel modes, user modes, ISUPPORT tokens, and so on.

What this PR adds

A HelpTopic type using the same inventory pattern already used by CommandRegistration, providing a compile-time registry for free-form help entries.

Usage

Register a topic anywhere in the codebase with inventory::submit!:

inventory::submit!(HelpTopic {
    topic: "CMODE_SECRET",
    lines: &[
        "CMODE_SECRET (+s)",
        "",
        "Marks the channel as secret. Secret channels are hidden from /LIST",
        "and /WHOIS for users who are not members.",
    ],
});

Look it up in a command handler:

// check command docs first, then fall back to free-form topics
if let Some(lines) = server.get_help_topic(&topic) {
    // send 704/705/706 numerics
}

New API

CommandDispatcher

• get_help_topic(topic: &str) -> Option<&'static [&'static str]> — case-insensitive lookup
• iter_help_topics() -> impl Iterator<Item = &'static HelpTopic> — enumerate all topics (for listing)

ClientServer — thin forwards to the above, so command handlers don't need to reach into the dispatcher directly.

How a HELP handler should combine both registries

// 1. Check command registry (populated by #[command_handler] doc comments — see #129)
// 2. Fall back to HelpTopic registry (this PR)
let lines = server.get_command_docs(&topic)   // added by #129
    .or_else(|| server.get_help_topic(&topic));

match lines {
    Some(lines) => { /* send 704/705/706 */ }
    None        => { /* send 524 HelpNotFound */ }
}

Changes

• sable_ircd/src/command/dispatcher.rs — HelpTopic struct, inventory::collect!(HelpTopic), two methods on CommandDispatcher
• sable_ircd/src/server/mod.rs — forwarding methods on ClientServer

[progval]

Sounds good, but this doesn't seem to be actually exposed to users.

And don't we want to use files instead? It has the extra benefit of being configurable

[internet-catte]

my plan, when I get back to it, was probably files.

[gfnord]

Hi,

The main reason for the inventory approach is consistency — CommandRegistration already uses the same pattern, so HelpTopic fits naturally alongside it with no new conventions to introduce. Help text registered this way lives next to the code it describes (e.g. a mode's doc sits in the same file as its implementation), which makes it easier to keep in sync when the implementation changes.

A file-based approach would add runtime I/O, deployment concerns (where do files live, are they bundled, what if they're missing), and a separate configuration surface that the rest of the codebase doesn't have. That said, this is just the registry infrastructure — if the consensus is to go file-based, it's straightforward to swap the backend later without changing how HelpTopic is used from command handlers.

What do you guys think?

[progval]

CommandRegistration is not configurable because it would require users to change the code.

A file-based approach would add runtime I/O, deployment concerns (where do files live, are they bundled, what if they're missing)

Solanum loads them on startup and rehash by listing a directory.

[gfnord]

I'll rework it to be file-based. Will work on it this weekend.

[internet-catte]

who will work on it, you or claudegpt?

[gfnord]

Claude will do the heavy work. Any concerns on that?

…

On Sat, Apr 18, 2026 at 1:52 PM internet-catte ***@***.***> wrote: *internet-catte* left a comment (Libera-Chat/sable#189) <#189?email_source=notifications&email_token=ABQBYX6EUKKIPBRSFSSK3DL4WPTJFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQ2TIMZZGU22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4274543955> who will work on it, you or claudegpt? — Reply to this email directly, view it on GitHub <#189?email_source=notifications&email_token=ABQBYX6EUKKIPBRSFSSK3DL4WPTJFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQ2TIMZZGU22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4274543955>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQBYX4ANFFHMRM5VNBPGQT4WPTJFAVCNFSM6AAAAACX6CD74OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENZUGU2DGOJVGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[spb]

As mentioned above, this is the wrong way to do this.