Repository navigation
Custom entry types matching special-command prefixes are misclassified #568
Description
Describe the bug
The splitter classifies block types with startswith, so valid custom entry
types whose names begin with comment, preamble, or string are routed to a
special-command parser instead of the ordinary entry parser.
For example, @commentary, @preamble_study, and @string_theory do not become
entries even though only the exact case-insensitive names comment, preamble,
and string should select those special block forms.
Reproducing
Version: current main (08e370a)
Code:
from bibtexparser import parse_string
for entry_type in ("commentary", "preamble_study", "string_theory"):
library = parse_string(
f"@{entry_type}{{key, title = {{Custom entry type}}}}"
)
assert [(entry.entry_type, entry.key) for entry in library.entries] == [
(entry_type, "key")
]The assertions fail on current main because the blocks are treated as special
commands rather than custom entries.
Expected behavior
Special-command dispatch should use an exact case-insensitive type comparison.
Longer custom type names should remain ordinary entries.
Workaround
Rename custom entry types so they do not begin with a special command name.
Remaining Questions (Optional)
- I would be willing to contribute a PR to fix this issue.
- This issue is a blocker, I'd be grateful for an early fix.
Activity
claell commentedon Jul 16, 2026
Draft PR #574 contains the exact-match dispatch fix and regressions for all three special-command prefixes.
MiWeiss commentedon Sep 2, 2026
Hi @claell — I'm posting this same note on all of your July 16 issues and PRs (#567–#597), so apologies for the form-letter feel.
I'm closing this. The batch — 13 issues, 18 PRs, ~3,000 lines, opened within a two-hour window with spec-style language and forward-references to PR numbers that didn't exist yet — reads as AI-generated rather than something you hit and verified by hand. Reviewing it properly would cost me more time than just fixing the parser myself.
If this is a real bug you've actually hit: reopen it with a concrete repro and a small, human-verified fix, and I'll review it. Any nontrivial design or API choice should be discussed in the issue first, before code is written. Otherwise, please disclose and verify AI-assisted contributions before submitting them in future.