mdtablefix doesn't correctly handle nested code blocks

[leynos]

Fenced blocks using three backticks inside blocks using four or more backticks or three tildes are not correctly handled.

The codefence logic should correctly track this nesting and take it into account when formatting.

[traycerai]

Plan

Observations

The compress_fences function in file:src/fences.rs processes lines independently without tracking fence state. When it encounters fence markers (3+ backticks/tildes) inside an already-open code block, it incorrectly compresses them instead of treating them as literal content. The FenceTracker in file:src/wrap/fence.rs correctly handles nested fences by tracking opening fence character and length, but this logic isn't used during fence compression preprocessing.

Approach

Modify file:src/fences.rs to use fence state tracking during compression and orphan specifier attachment. The compress_fences function will use a FenceTracker instance to determine whether a fence-like line is an actual fence delimiter or content inside a code block. Only actual fence delimiters should be compressed. The attach_orphan_specifiers function needs similar treatment to avoid attaching specifiers to fence markers that are inside code blocks.

Implementation Steps

1. Update compress_fences Function

File: file:src/fences.rs

Modify the compress_fences function (lines 76-92) to track fence state:

• Import FenceTracker from crate::wrap::FenceTracker
• Initialize a FenceTracker instance before processing lines
• For each line, first check if it's a fence using the tracker's logic
• Only compress lines that are actual fence delimiters (when tracker state changes)
• Lines inside fences that match the fence regex should be left unchanged
• The tracker should use the ORIGINAL fence marker (before compression) to properly track nesting

Key Logic:

• Before compressing a line, determine if it would open/close a fence using the original marker length
• If inside a fence and the line doesn't close it, preserve the line as-is
• If the line opens or closes a fence, compress it to ```

2. Update attach_orphan_specifiers Function

File: file:src/fences.rs

Modify the attach_orphan_specifiers function (lines 149-182) to respect fence boundaries:

• Add a FenceTracker instance to track fence state
• Before checking if a line is an orphan specifier, verify we're not inside a fence
• Only process orphan specifiers that appear outside of fenced code blocks
• When encountering fence markers, update the tracker state

Key Logic:

• Skip orphan specifier detection when tracker.in_fence() returns true
• Update tracker state for each fence line encountered
• Preserve the existing logic for lines outside fences

3. Add Comprehensive Tests

File: file:tests/fences.rs

Add test cases for nested fence scenarios:

• Test case: Four backticks with three backticks inside

  • Input: ``````, , code, , ````
  • Expected: , ```, code, ```,

• Test case: Three tildes with three backticks inside

  • Input: ~~~, , code, , ~~~
  • Expected: , , code, ,

• Test case: Multiple levels of nesting with different markers

  • Verify that inner fences remain unchanged when inside outer fences

• Test case: Orphan specifiers inside fenced blocks should not be attached

  • Input: , Rust, ```, code, ```,
  • Expected: , Rust, ```, code, ```, (Rust should NOT be attached)

4. Update Unit Tests for FenceTracker

File: file:src/wrap/tests/fence_tracker.rs

Add explicit test cases documenting the expected behavior:

• Test that verifies three backticks inside four backticks are ignored
• Test that verifies three backticks inside three tildes are ignored
• Test that verifies the tracker correctly handles the original fence length before compression

5. Integration Testing

File: file:tests/wrap/fence_behaviour.rs

Add integration tests that verify end-to-end behavior:

• Test that nested fences are preserved through the full processing pipeline
• Test that wrapping doesn't occur inside nested fence content
• Test that table detection doesn't trigger inside nested fences

Implementation Notes

Critical Consideration: The compress_fences function currently processes lines before they reach the FenceTracker used in file:src/process.rs. This means we need to track fences using the ORIGINAL fence markers (before compression) to correctly identify nesting.

Sequence Diagram:

sequenceDiagram
    participant Input as Input Lines
    participant CF as compress_fences
    participant FT as FenceTracker
    participant Output as Output Lines

    Input->>CF: ````markdown
    CF->>FT: observe("````markdown")
    FT-->>CF: true (opens fence)
    CF->>Output: ```markdown (compressed)
    
    Input->>CF: ```
    CF->>FT: observe("```")
    FT-->>CF: false (inside fence, ignored)
    CF->>Output: ``` (unchanged)
    
    Input->>CF: code
    CF->>FT: observe("code")
    FT-->>CF: false (not a fence)
    CF->>Output: code (unchanged)
    
    Input->>CF: ```
    CF->>FT: observe("```")
    FT-->>CF: false (inside fence, ignored)
    CF->>Output: ``` (unchanged)
    
    Input->>CF: ````
    CF->>FT: observe("````")
    FT-->>CF: true (closes fence)
    CF->>Output: ``` (compressed)

Loading

Edge Cases to Handle:

• Mixed fence types (backticks inside tildes, tildes inside backticks)
• Indented fences with nesting
• Fence markers with info strings at various nesting levels
• Empty fences (opening and closing on same line)

Import In IDE

🤖 Prompt for AI Agents

## Observations

The `compress_fences` function in file:`src/fences.rs` processes lines independently without tracking fence state. When it encounters fence markers (3+ backticks/tildes) inside an already-open code block, it incorrectly compresses them instead of treating them as literal content. The `FenceTracker` in file:`src/wrap/fence.rs` correctly handles nested fences by tracking opening fence character and length, but this logic isn't used during fence compression preprocessing.

## Approach

Modify file:`src/fences.rs` to use fence state tracking during compression and orphan specifier attachment. The `compress_fences` function will use a `FenceTracker` instance to determine whether a fence-like line is an actual fence delimiter or content inside a code block. Only actual fence delimiters should be compressed. The `attach_orphan_specifiers` function needs similar treatment to avoid attaching specifiers to fence markers that are inside code blocks.

## Implementation Steps

### 1. Update `compress_fences` Function

**File**: file:`src/fences.rs`

Modify the `compress_fences` function (lines 76-92) to track fence state:

- Import `FenceTracker` from `crate::wrap::FenceTracker`
- Initialize a `FenceTracker` instance before processing lines
- For each line, first check if it's a fence using the tracker's logic
- Only compress lines that are actual fence delimiters (when tracker state changes)
- Lines inside fences that match the fence regex should be left unchanged
- The tracker should use the ORIGINAL fence marker (before compression) to properly track nesting

**Key Logic**:
- Before compressing a line, determine if it would open/close a fence using the original marker length
- If inside a fence and the line doesn't close it, preserve the line as-is
- If the line opens or closes a fence, compress it to ```

### 2. Update `attach_orphan_specifiers` Function

**File**: file:`src/fences.rs`

Modify the `attach_orphan_specifiers` function (lines 149-182) to respect fence boundaries:

- Add a `FenceTracker` instance to track fence state
- Before checking if a line is an orphan specifier, verify we're not inside a fence
- Only process orphan specifiers that appear outside of fenced code blocks
- When encountering fence markers, update the tracker state

**Key Logic**:
- Skip orphan specifier detection when `tracker.in_fence()` returns true
- Update tracker state for each fence line encountered
- Preserve the existing logic for lines outside fences

### 3. Add Comprehensive Tests

**File**: file:`tests/fences.rs`

Add test cases for nested fence scenarios:

- Test case: Four backticks with three backticks inside
  - Input: ``````, ```, code, ```, ````
  - Expected: ````, ```, code, ```, ````
  
- Test case: Three tildes with three backticks inside
  - Input: ~~~, ```, code, ```, ~~~
  - Expected: ```, ```, code, ```, ```

- Test case: Multiple levels of nesting with different markers
  - Verify that inner fences remain unchanged when inside outer fences

- Test case: Orphan specifiers inside fenced blocks should not be attached
  - Input: ````, Rust, ```, code, ```, ````
  - Expected: ````, Rust, ```, code, ```, ```` (Rust should NOT be attached)

### 4. Update Unit Tests for FenceTracker

**File**: file:`src/wrap/tests/fence_tracker.rs`

Add explicit test cases documenting the expected behavior:

- Test that verifies three backticks inside four backticks are ignored
- Test that verifies three backticks inside three tildes are ignored
- Test that verifies the tracker correctly handles the original fence length before compression

### 5. Integration Testing

**File**: file:`tests/wrap/fence_behaviour.rs`

Add integration tests that verify end-to-end behavior:

- Test that nested fences are preserved through the full processing pipeline
- Test that wrapping doesn't occur inside nested fence content
- Test that table detection doesn't trigger inside nested fences

## Implementation Notes

**Critical Consideration**: The `compress_fences` function currently processes lines before they reach the `FenceTracker` used in file:`src/process.rs`. This means we need to track fences using the ORIGINAL fence markers (before compression) to correctly identify nesting.

**Sequence Diagram**:

```mermaid
sequenceDiagram
    participant Input as Input Lines
    participant CF as compress_fences
    participant FT as FenceTracker
    participant Output as Output Lines

    Input->>CF: ````markdown
    CF->>FT: observe("````markdown")
    FT-->>CF: true (opens fence)
    CF->>Output: ```markdown (compressed)
    
    Input->>CF: ```
    CF->>FT: observe("```")
    FT-->>CF: false (inside fence, ignored)
    CF->>Output: ``` (unchanged)
    
    Input->>CF: code
    CF->>FT: observe("code")
    FT-->>CF: false (not a fence)
    CF->>Output: code (unchanged)
    
    Input->>CF: ```
    CF->>FT: observe("```")
    FT-->>CF: false (inside fence, ignored)
    CF->>Output: ``` (unchanged)
    
    Input->>CF: ````
    CF->>FT: observe("````")
    FT-->>CF: true (closes fence)
    CF->>Output: ``` (compressed)
```

**Edge Cases to Handle**:
- Mixed fence types (backticks inside tildes, tildes inside backticks)
- Indented fences with nesting
- Fence markers with info strings at various nesting levels
- Empty fences (opening and closing on same line)

---

Execution Information

Branch: main
Commit: d427f7b

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.