bug: pipe table inside a markdown code block is wider than `code.width = 'block'`, so cell text gets hidden

Start by reading core/handlers.lua and code.lua, which the issue identifies as the handler ordering and block sizing entry points; compare how the outer fenced block is sized with how the injected Markdown table is rendered. Reproduce with the provided nested table and code = { width = 'block', right_pad = 1 }. Done means the rendered table fits its block or its text remains visible, with existing block sizing behavior preserved.

Neovim version (nvim -v)

0.12.6

Neovim distribution

N/A

Operating system

Linux (Ubuntu, kernel 6.8)

Terminal emulator / GUI

WezTerm

Describe the bug

When a pipe table is written inside a fenced code block whose language is markdown,
the rendered table can be wider than the code block, which is sized with width = 'block'.
Buffer characters that end up past the block's right edge are hidden by the background
virt_text_win_col padding. Inline padding and the overlay │ are still drawn, so one
character goes missing in the middle of a cell.

Input (outer fence is 4 backticks only for GitHub display):

```markdown
| id | name |
|-|-|
|1| ichiro|
|100|momotake|
```

Rendered with the minimal configuration below (the e of momotake is missing):

┌─────┬──────────┐
│ id  │ name     │
├─────┼──────────┤
│ 1   │ ichiro   │
│ 100 │ momotak  │
└─────┴──────────┘

What happens:

• The code block body width is computed from the raw line widths:
  the longest line is |100|momotake|, which is 14 cells, plus right_pad = 1, so 15.
• The table renderer adds padding around tightly written cells (|100| -> │ 100 │),
  so that row is rendered 18 cells wide and the e lands in column 15.
• The background padding at virt_text_win_col = 15 covers buffer text only, so the e
  is hidden. The inline spaces and the │ overlay after it are still drawn.

If no buffer character crosses the edge, nothing is hidden, but the table still sticks out
past the block. For example, with momo instead of momotake, the table is 16 cells wide
while the block is only 14. Tables already written with spaces
(| 100 | momotake |) barely change width, so they are not affected.

doc/limitations.md says the raw string width "is if anything going to be an over-estimate".
Nested markdown tables are a case where it is an under-estimate.

Expected behavior

The code block's block width accounts for the rendered width of the nested table,
or at least never hides the table's text.

Healthcheck output

==============================================================================
render-markdown:                                                            ✅

render-markdown.nvim [versions] ~
- ✅ OK neovim >= 0.11
- ✅ OK tree-sitter ABI: 15
- ✅ OK plugin: 8.14.1

render-markdown.nvim [configuration] ~
- ✅ OK valid

render-markdown.nvim [tree-sitter markdown] ~
- ✅ OK parser: installed
- ✅ OK ABI: 15
- ✅ OK highlights: ~/.local/share/nvim/site/queries/markdown/highlights.scm
- ✅ OK highlighter: enabled

render-markdown.nvim [tree-sitter markdown_inline] ~
- ✅ OK parser: installed
- ✅ OK ABI: 15
- ✅ OK highlights: ~/.local/share/nvim/site/queries/markdown_inline/highlights.scm

render-markdown.nvim [tree-sitter html] ~
- ✅ OK parser: installed
- ✅ OK ABI: 14

render-markdown.nvim [tree-sitter latex] ~
- ✅ OK parser: installed
- ✅ OK ABI: 15

render-markdown.nvim [tree-sitter yaml] ~
- ✅ OK parser: installed
- ✅ OK ABI: 15

render-markdown.nvim [icons] ~
- ✅ OK using: mini.icons

render-markdown.nvim [latex] ~
- ✅ OK using: { "utftex", "latex2text" }

render-markdown.nvim [conflicts] ~
- ✅ OK headlines: not installed
- ✅ OK markview: not installed
- ✅ OK obsidian: installed but should not conflict
- ✅ OK snacks: not installed

Plugin configuration

Minimal configuration that reproduces it:


require('render-markdown').setup({
    code = { width = 'block', right_pad = 1 },
})

Plugin error log

N/A

Confirmations

• I have updated this plugin to the latest version using my plugin manager
• I have updated all treesitter parsers (:TSUpdate)
• I have provided the text contained in all screenshots as raw text in this issue. This means if there is a screenshot below it is the copy pasted contents of the file in the screenshot. I understand that my issue will be closed if I have not.

Additional information

This looks like the same root cause as #580: the outer fenced_code_block is rendered
from the top-level tree before the injected markdown tree, so it cannot see how wide the
nested content becomes. One idea I have not tried yet: process nested markdown roots before
their parent in core/handlers.lua, record their marks in the request context, and have
code.lua size the block with context:width() per row. But it changes
handler ordering, and recording marks for the top-level tree has side effects (for example,
section indent marks would feed into heading width), so I wanted to ask before opening a PR.

Would you be open to that direction, or would you prefer another approach? I'm happy to
send a PR.