Skip to content

Make string reference expansion opt-in #590

Closed

Description

@claell

Problem

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:

layers = [
    ResolveStringReferencesMiddleware(),
    RemoveEnclosingMiddleware(),
]

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.

Activity

  1. claell commented on Jul 16, 2026

    @claell
    ContributorAuthor

    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.

  2. MiWeiss commented on Sep 2, 2026

    @MiWeiss
    Collaborator

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions