Remove duplicate fence detection code in src/wrap.rs

[coderabbitai]

Issue Description

There is duplicate fence detection logic in src/wrap.rs that should be consolidated to use the implementation from the tokenize module.

Current Problem

The file src/wrap.rs contains:

• A local FENCE_RE static regex
• A local is_fence function that uses this regex

This duplicates the fence detection logic already implemented in the tokenize module.

Proposed Solution

Remove the local FENCE_RE static and update the is_fence function to call crate::tokenize::is_fence(line) instead.

References

• PR: Refactor wrap prefixes and doc fix #147
• Comment: Refactor wrap prefixes and doc fix #147 (comment)
• Requested by: @leynos

Code Location

• File: src/wrap.rs
• Lines: ~23-24 and ~213

[leynos]

@coderabbitai looking at the codebase, is this issue still relevant? If the issue has been fixed in the code, does the documentation reflect this?

If it is still relevant, please provide an assessment of the issue criticality (critical, high, medium or low), based on risk of the issue impacting the user and the anticipated blast radius.

Once a decision has been made, apply the appropriate label.

If the issue is documentation ONLY (i.e., no code changes needed), apply the documentation label in addition to the appropriate criticality label.

Please also provide an impact of the required changes.

[coderabbitai]

This issue has been resolved by PR #192 and PR #236.

Resolution:

• PR Preserve fence languages during wrapping #192 (merged 2025-08-19) created a dedicated src/wrap/fence.rs module and moved the fence detection logic there, eliminating the duplicate code from src/wrap.rs.
• PR Unify fence tracking across modules #236 (merged 2025-09-28) further unified fence tracking by introducing FenceTracker and consolidating fence semantics across all modules.

Current state:

• src/wrap.rs now imports fence functionality via pub use fence::{FenceTracker, is_fence};
• The fence module (src/wrap/fence.rs) contains the canonical FENCE_RE regex and is_fence function
• The tokenize module correctly uses super::is_fence(line) to reference the shared implementation

The implemented solution is actually better than originally proposed, as it created a dedicated fence module that provides consistent fence semantics across the entire codebase.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Check if src/wrap.rs exists and examine its content for fence detection code
echo "=== Examining src/wrap.rs for fence detection code ==="
if [ -f "src/wrap.rs" ]; then
    cat src/wrap.rs
else
    echo "File src/wrap.rs not found"
fi

echo -e "\n=== Checking tokenize module for is_fence function ==="
# Find and examine tokenize module files
fd -e rs tokenize --exec cat {}

Length of output: 22254

---

🏁 Script executed:

#!/bin/bash

# Check the fence module for is_fence implementation
echo "=== Examining src/wrap/fence.rs ==="
if [ -f "src/wrap/fence.rs" ]; then
    cat src/wrap/fence.rs
else
    echo "File src/wrap/fence.rs not found"
fi

echo -e "\n=== Checking git history for when this was fixed ==="
# Look for commits that modified wrap.rs and removed FENCE_RE
git log --all --oneline --grep="fence" --grep="duplicate" --grep="177" -i -- src/wrap.rs | head -20

echo -e "\n=== Check if FENCE_RE was ever in wrap.rs ==="
git log -p --all -- src/wrap.rs | grep -A5 -B5 "FENCE_RE" | head -40

Length of output: 4328

---

🏁 Script executed:

#!/bin/bash

# Check the specific commit that unified fence tracking
echo "=== Examining commit e300d7f (Unify fence tracking across modules) ==="
git show e300d7f --stat

echo -e "\n=== Check the diff for wrap.rs in that commit ==="
git show e300d7f -- src/wrap.rs | head -100

echo -e "\n=== Check when the fence module was created ==="
git log --oneline --diff-filter=A -- src/wrap/fence.rs

echo -e "\n=== Check if issue #177 references are in any commits ==="
git log --all --oneline --grep="#177" -i | head -10

Length of output: 4236

---

🏁 Script executed:

#!/bin/bash

# Check PR #192 which seems to have fixed this
echo "=== Examining PR #192 details ==="
gh pr view 192 --json title,body,state,mergedAt,closedAt,number,url

echo -e "\n=== Check if issue #177 was referenced or closed by any PR ==="
gh issue view 177 --json title,body,state,closedAt,number,url,timelineItems --jq '.timelineItems[] | select(.eventType == "CrossReferencedEvent" or .eventType == "ClosedEvent")'

echo -e "\n=== Check if there are any other references to issue 177 ==="
gh issue view 177 --json title,body,state,closedAt,number,url,labels

echo -e "\n=== Search for references to issue 177 in closed PRs ==="
gh pr list --state all --search "177" --json number,title,state,url --limit 10

Length of output: 4084

---

🏁 Script executed:

#!/bin/bash

# Let's verify the original state by checking PR #147 where the issue was raised
echo "=== Examining PR #147 (where issue was originally raised) ==="
gh pr view 147 --json title,body,mergedAt,number,url

echo -e "\n=== Look at the specific comment that raised this issue ==="
gh api repos/leynos/mdtablefix/pulls/147/comments | jq '.[] | select(.id == 2249003063) | {user: .user.login, body: .body, created_at: .created_at}'

echo -e "\n=== Check the state of src/wrap.rs at the time of PR #147 ==="
# Get the merge commit for PR #147
MERGE_SHA=$(gh pr view 147 --json mergeCommit --jq '.mergeCommit.oid')
echo "PR #147 merge commit: $MERGE_SHA"

if [ -n "$MERGE_SHA" ]; then
    echo -e "\n=== Content of src/wrap.rs at PR #147 merge (looking for FENCE_RE) ==="
    git show $MERGE_SHA:src/wrap.rs | grep -A2 -B2 "FENCE_RE\|is_fence" | head -40
fi

Length of output: 2932

---

🏁 Script executed:

#!/bin/bash

# Close the issue as it has been resolved
echo "=== Closing issue #177 as completed ==="
gh issue close 177 --reason completed --comment "This issue has been resolved by PR #192 and PR #236.

**Resolution:**
- PR #192 (merged 2025-08-19) created a dedicated \`src/wrap/fence.rs\` module and moved the fence detection logic there, eliminating the duplicate code from \`src/wrap.rs\`.
- PR #236 (merged 2025-09-28) further unified fence tracking by introducing \`FenceTracker\` and consolidating fence semantics across all modules.

**Current state:**
- \`src/wrap.rs\` now imports fence functionality via \`pub use fence::{FenceTracker, is_fence};\`
- The fence module (\`src/wrap/fence.rs\`) contains the canonical \`FENCE_RE\` regex and \`is_fence\` function
- The tokenize module correctly uses \`super::is_fence(line)\` to reference the shared implementation

The implemented solution is actually better than originally proposed, as it created a dedicated fence module that provides consistent fence semantics across the entire codebase."

Length of output: 131

---

@leynos This issue is no longer relevant - it has been completely resolved by subsequent PRs.

Resolution Status

The duplicate fence detection code has been eliminated. Here's what happened:

At the time issue was raised (PR #147, Aug 2025):

• src/wrap.rs contained local FENCE_RE static regex at lines 23-24
• src/wrap.rs contained local is_fence function at line 213
• This duplicated logic from the tokenize module

How it was fixed:

1. PR Preserve fence languages during wrapping #192 (merged 19 Aug 2025): Created dedicated src/wrap/fence.rs module

   • Moved FENCE_RE and is_fence to the new fence module
   • Enhanced is_fence to return fence components (indent, marker, info string)
   • Eliminated duplication from src/wrap.rs

2. PR Unify fence tracking across modules #236 (merged 28 Sept 2025): Unified fence tracking across all modules

   • Introduced FenceTracker for consistent fence semantics
   • Consolidated fence handling across wrap, breaks, lists, footnotes, and processing modules
   • Further improved the architecture beyond the original issue scope

Current state:

• src/wrap.rs imports via pub use fence::{FenceTracker, is_fence};
• src/wrap/fence.rs contains the canonical implementation
• src/wrap/tokenize.rs uses super::is_fence(line) to reference the shared implementation
• Zero duplication exists

Assessment

Since the issue has been resolved, criticality assessment is not applicable. However, for reference:

• Original criticality: Would have been low - code duplication with minimal user impact, primarily a maintainability concern
• Blast radius: Internal refactoring only, no user-facing changes

Documentation

No documentation updates needed - this was internal code refactoring with no API changes.

Action Taken

I've closed issue #177 as completed with a detailed explanation of the resolution.