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
{{ message }}
Repository navigation
Define an idempotent failed-block writing policy #588
ParsingFailedBlock.raw is the only retained representation of input the parser could not model. The writer currently prepends a generated warning comment to that source by default. On the next parse, the warning becomes an ordinary implicit comment; writing again adds another warning. Repeated read/write cycles therefore accumulate generated content even when the user changes nothing.
There is also no fail-closed writer mode for applications that must refuse export while any parse failure remains.
Proposed policy
Add an explicit BibtexFormat.failed_block_policy with three values:
"preserve" (proposed default): write retained raw failed blocks unchanged;
"annotate": prepend the configured diagnostic, while recognizing and replacing an identical existing annotation so repeated cycles are idempotent; and
"raise": refuse to write if the library contains any failed block, reporting all failures together.
An unknown policy must raise immediately. Failed blocks without raw source remain unwritable under every policy. There should be no silent discard mode.
This setting applies only to failed blocks. Normal parsed blocks must continue to serialize from their current model state because their cached raw source may be stale after middleware or user edits.
Compatibility
Changing the default from annotation to preservation is intentional but user-visible. The former behavior remains available as "annotate", and strict applications gain "raise". The documentation should call out the change and the fact that canonical writing is not a byte-identical concrete-syntax editor for normal blocks.
The configurable annotation text is already tracked by #530 / PR #566. A standalone implementation of this proposal may carry that fix as a clearly separated prerequisite until it merges.
A validated draft implementation is available in PR #589: #589. It separates the existing #530 prerequisite, the three-policy API, and annotation idempotence into atomic commits.
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 validated draft implementation is available in PR #589: #589. It separates the existing #530 prerequisite, the three-policy API, and annotation idempotence into atomic commits.
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.