You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The default parse stack applies ResolveStringReferencesMiddleware. An entry such as journal = journalName therefore becomes the current literal value of @string{journalName = ...}. Writing the parsed library emits the expanded value and loses the relationship to the macro definition.
That is not merely formatting normalization: later edits to the @string definition no longer update the entry, and a parse/write cycle creates many duplicated literals. The original reference cannot be reconstructed reliably from the expanded text.
Proposed default
Remove ResolveStringReferencesMiddleware from the default parse stack so references remain references. Keep the middleware public and document an explicit dereferencing profile:
Ordering matters because interpolation must see the original expression before ordinary enclosure removal changes its representation.
Add public-entry-point tests proving both contracts:
default parsing and writing retain @string linkage; and
callers who explicitly request interpolation receive expanded values.
Compatibility
This is a user-visible default change. Existing users who rely on immediate expanded values must add the middleware explicitly. The alternative is irreversible semantic loss during ordinary parse/write use, so preservation is the safer default for a bibliography codec.
Concatenated expressions and cyclic/unresolved references are related to #396 but are not prerequisites for deciding the default. The initial implementation should use basic references and remain independently reviewable.
A standalone, validated draft implementation is available in PR #591: #591. It keeps the existing interpolation middleware as the explicit compatibility path and does not depend on the broader #396 work.
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.
Activity
claell commentedon Jul 16, 2026
A standalone, validated draft implementation is available in PR #591: #591. It keeps the existing interpolation middleware as the explicit compatibility path and does not depend on the broader #396 work.
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.