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

feature: optional preview-buffer rendering for wrapped, navigable tables

Cerrado
#689 2 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
lua, markdown, neovim

Línea de trabajo

Empieza leyendo el renderizador de vista previa existente y su separación entre fuente y presentación; después, sigue el renderizado de tablas y el comportamiento de actualización. Compara la proyección, el ajuste de línea, las asignaciones de origen, el redimensionamiento y el comportamiento de edición/cursor requeridos por el prototipo con las interfaces actuales. Se considera terminado cuando exista un modo de vista previa opcional acordado o una interfaz de companion plugin compatible que preserve la edición del origen, el guardado, la navegación y el renderizado habitual de Markdown.

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

Descripción

enhancement
Is your feature request related to a problem? Please describe.

Long table cells are difficult to read in narrow windows. Wrapping the underlying Markdown line does not
preserve the table's column layout, while generated virtual lines require additional handling for cursor
movement, selection, and copying.

Related requests include #536 and
#616.

Describe the solution you'd like

I have implemented a prototype that renders tables as real text rows in a separate preview buffer, while
keeping the original Markdown buffer responsible for editing, undo history, and saving.

Short columns retain their natural width where space permits. The remaining width is distributed among
longer columns. Cell contents wrap at word boundaries, with oversized words or identifiers split when
necessary. Each table row expands to accommodate its tallest cell.

Ordinary Markdown around the table continues to use render-markdown.nvim.

Demonstration:

Image

The GIF shows long descriptions wrapping beside aligned short cells, an oversized identifier splitting
across lines, cursor movement through wrapped content, visual selection and copying, and a quick status edit
followed by undo/redo.

Benefits

  • Readable tables within the window: long cells expand vertically while preserving column alignment.

  • Native navigation and copying: continuation rows are actual buffer lines, so movement, search, selection,
    and yanking work on their text.

  • Source-backed editing: supported edit commands return to the corresponding source cell; preview resumes
    afterward.

  • Incremental updates: unchanged table layouts can be cached, with only changed preview ranges updated.

Costs and limitations

The additional preview buffer requires memory, layout work, and source-position mappings. Those mappings
must account for wrapped lines, UTF-8, links, and inline formatting.

Editing also becomes more complex: the preview remains read-only, supported quick edits run in the source
buffer, and arbitrary visual edits require switching to source mode. Saving, modified state, link
navigation, and cursor restoration must preserve the source buffer's behavior.

The prototype demonstrates feasibility; it does not establish a performance improvement over the current
renderer.

Possible upstream support

The existing preview already separates source and presentation. Supporting this approach would additionally
require:

  • Table projection into real display rows, with highlights and source mappings.
  • A way to exclude generated table rows from ordinary Markdown parsing.
  • Refresh handling for source edits and window resizing, with source-position preservation.

This could be an optional preview mode or a supported interface for a companion plugin.

The same projection interface could later support Mermaid diagrams through an external renderer, though
precise diagram-to-source mapping would require additional metadata.

Describe alternatives you've considered

Using a separate table-viewing plugin is another option. It could open large tables in a dedicated buffer with wrapping, navigation, and copying support.

Additional information

No response

Lenguaje dominante
Lua
Estrellas
5.1k
Forks
144
Métricas de merge de PR
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.