Recent commits to derivepassphrase.git (ce74bd6fd43e36a55bee58c8bd520f2bb21bc8cd) https://git.schokokeks.org/derivepassphrase.git/tree/ce74bd6fd43e36a55bee58c8bd520f2bb21bc8cd Recent commits feed provided by GitList. Add the command-line specification under the planned new parser Translate derivepassphrase's existing command-line interface to the planned new parser infrastructure. (The new CLI spec is not connected to anything yet.) https://git.schokokeks.org/derivepassphrase.git/commit/ce74bd6fd43e36a55bee58c8bd520f2bb21bc8cd software@the13thletter.info (Marco Ricci) Sun, 16 Aug 2026 16:58:20 +0200 ce74bd6fd43e36a55bee58c8bd520f2bb21bc8cd Add JSON-compatible and usage message-compatible serialization https://git.schokokeks.org/derivepassphrase.git/commit/be982120ea7e938908f19890c045f9c8ed134506 software@the13thletter.info (Marco Ricci) Sun, 16 Aug 2026 16:10:07 +0200 be982120ea7e938908f19890c045f9c8ed134506 Add an option filter for short options and option aliases https://git.schokokeks.org/derivepassphrase.git/commit/06fc8a12e108f2d64985a8e458585515de3ed81d software@the13thletter.info (Marco Ricci) Sun, 16 Aug 2026 16:09:04 +0200 06fc8a12e108f2d64985a8e458585515de3ed81d Add parser stages for the planned new command-line argument parser These are the actual parser steps. They must be run in sequence, and generally only act on the current "section" of the command-line (up to the next subcommand boundary). - The first step normalizes the command-line, inserting the `--` pseudo-option, unclustering clustered options, using canonical option and subcommand names, and appending option arguments to the argument in `--opt=arg` style. This step relies on the `canon_map` property of CLISubcommand objects. - The second step scans for eager options, if necessary replacing the whole command-line with the eager option. This step too relies on the `canon_map` property of CLISubcommand objects. - The third step locates the subcommand boundary, if any, and returns the partial command-line up to that boundary, and a new parser state for the remaining section. This step too relies on the `canon_map` property of CLISubcommand objects. - An additional "complete" step calls the first three steps, in order, on each section of the command-line, and returns the accumulated results. This step relies on the `canon_map` property of CLISubcommand objects, indirectly, via the first three steps. https://git.schokokeks.org/derivepassphrase.git/commit/9a259fe2e846879dacbe0d2883aee4a1c1027f8d software@the13thletter.info (Marco Ricci) Sun, 16 Aug 2026 16:05:46 +0200 9a259fe2e846879dacbe0d2883aee4a1c1027f8d Add a canon_map property to the CLISubcommand classes The canonical map of option or subcommand names maps such a name to the respective option or subcommand object. It is a dependent attribute (and thus should be excluded from `__init__`, `__eq__` and `__lt__`, etc.) and somewhat expensive to compute, so we cache the result in a global weak key dictionary, because the subcommand objects themselves are immutable. https://git.schokokeks.org/derivepassphrase.git/commit/8d99ee9c44baa6c55d1456625775aacf7ea72157 software@the13thletter.info (Marco Ricci) Sun, 16 Aug 2026 15:37:05 +0200 8d99ee9c44baa6c55d1456625775aacf7ea72157 Add data structures for the planned new command-line argument parser The command-line interface is organized as a hierarchy of "subcommand" objects, which contain "option group" objects, which contain "option" objects. The parser is multi-stage, and has an explicit "state" object containing the top-level subcommand specification and the command-line to parse. The parser steps are monadic, similar to the "Maybe" monad: each step depends only on the current state, and returns a ParseFailure or ParseEarlyExit state (which skips any further computation), or a ParseSuccess state (which does not). This commit only contains the data structures, not the actual parser steps. https://git.schokokeks.org/derivepassphrase.git/commit/b4e99a3c45caea935db40ea2b408e1d754056c6e software@the13thletter.info (Marco Ricci) Sun, 16 Aug 2026 15:36:09 +0200 b4e99a3c45caea935db40ea2b408e1d754056c6e Add new help text messages with option specs and metavars expanded inline For all option one-line descriptions, add variants where the option specification (as it appears in the help text) is included inline, as a first line/first paragraph, and the one-line description as the second paragraph. In these variants, metavars are expanded inline, as in the previous commit. The inline expansion of metavars follows the reasoning from the previous commit. The one-line description is due to a planned new command-line argument parser, which is strictly a parser and thus leaves option grouping, mutually exclusive options and help text generation to the application. Keeping the formatted option specification in the help text string gives the translators more context, and also allows the application (the help text formatting part at least) to rediscover the grouping or mutual exclusivity based on identical help text strings. https://git.schokokeks.org/derivepassphrase.git/commit/01bff8cba2afa4b25d804df972a0e6350107b88d software@the13thletter.info (Marco Ricci) Sun, 16 Aug 2026 09:20:06 +0200 01bff8cba2afa4b25d804df972a0e6350107b88d Add new help and error messages with metavars expanded inline For all texts that aren't one-line option descriptions, add versions of the text where the metavar is expanded inline, instead of referencing a different translation string inline. If multiple texts need to use the same metavar consistently, pick one of them, and reference that canonical entry in the other entries' commentary. This is partly based on search engine/AI feedback on how other projects solve the problem of wanting to explain mini-formats or other conventions common to multiple messages to translators: there is no place to put (machine-readable) references or common explanation, so it is typical instead to refer inline in the translation commentary to a canonical entry that contains longer-form explanation instead. This is rather awkward to work with if there are multiple layers of expansion (metavars) in the messages, so it is probably easier on the translators to include the metavar inline and just note that "canonical text X" uses the same metavar. Of course, the canonical text should be short enough to be easily included inline in the commentary. https://git.schokokeks.org/derivepassphrase.git/commit/9df093ffb32d551e062bcbe2d4f6dedcbf713194 software@the13thletter.info (Marco Ricci) Sun, 16 Aug 2026 08:52:13 +0200 9df093ffb32d551e062bcbe2d4f6dedcbf713194 Update wishlist to post-v0.6.1 https://git.schokokeks.org/derivepassphrase.git/commit/96a6de836795685b74c4172cf8f807fd187bce47 software@the13thletter.info (Marco Ricci) Mon, 06 Jul 2026 21:29:46 +0200 96a6de836795685b74c4172cf8f807fd187bce47 Release 0.6.1 https://git.schokokeks.org/derivepassphrase.git/commit/84cfbefc857e59bbd2379d5201d338fa493d6d54 software@the13thletter.info (Marco Ricci) Mon, 06 Jul 2026 21:28:06 +0200 84cfbefc857e59bbd2379d5201d338fa493d6d54