Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#706 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 6 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
lua, neovim
Área
frontend, tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Lua
Estrellas
5.2k
Forks
145
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MeanderingProgrammer/render-markdown.nvim

Todos los issues de MeanderingProgrammer/render-markdown.nvim

Issues similares

Más issues de Lua

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.