Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#706 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 6 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
lua, neovim
Ambito
frontend, tooling

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
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.

Lingua principale
Lua
Stelle
5.2k
Fork
145
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MeanderingProgrammer/render-markdown.nvim

Tutte le issue di MeanderingProgrammer/render-markdown.nvim

Issue simili

Altre issue su Lua

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.