Normalize --chapters filter input to zero-padded chapter numbers #1
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Symptom
The
--chaptersfilter onalpha-id suggestsilently returns zeroresults whenever the supplied value is not a two-digit zero-padded
chapter number. The filter takes the value verbatim and compares it by
exact string equality, so the natural inputs a user reaches for —
--chapters E,I(code letters) or--chapters 4,9(un-padded numbers)— never match any candidate and the suggestion list comes back empty
with no diagnostic.
Reproduction
Input file with one extracted phrase per line:
Root cause
roman_to_paddedformatsthe Arabic chapter number as
format!("{n:02}"), yielding "01".."22"(
src/claml.rs:17). JSON output confirms values like "04", "14".string equality, with no normalization:
if !ch.iter().any(|c| c == &t.chapter)(src/model.rs:51).pad:
chapters.map(|c| c.split(',').map(|s| s.trim().to_string()).collect())(
src/bin/alpha_id.rs).So "4" != "04" and the entire candidate set is filtered out.
Two distinct defects
are the intuitive inputs but never match. Normalizing the filter
input — pad bare 1-2 digit numbers to two digits, and/or map ICD code
letters to their chapter number — would remove the trap.
--chaptersvalue that cannot match anyknown chapter produces an empty list indistinguishable from "no
clinical match". A warning on an unrecognized/never-matching chapter
token would make the misuse visible.
Acceptance
--chapters 4and--chapters 04behave identically.--chapterstoken that matches no known chapter emits a warning tostderr rather than silently yielding zero results.