Is your feature request related to a problem? Please describe.
Currently, render-markdown.nvim renders pipe tables with only a single separator line below the header row:
┌─────┬─────┐
│ H1 │ H2 │
├─────┼─────┤ ← only one separator
│ a │ b │
│ c │ d │
│ e │ f │
└─────┴─────┘
When cells contain multi-line content (wrapped links, <br>, long inline code), it becomes very hard to tell where one row ends and the next begins without a visual divider between every data row.
Describe the solution you'd like
Describe the solution you'd like
A "full_grid" style option (e.g. style = 'full_grid' under pipe_table) that renders a ├─────┼─────┤ separator between every row, not just below the header:
┌─────┬─────┐
│ H1 │ H2 │
├─────┼─────┤
│ a │ b │
├─────┼─────┤
│ c │ d │
├─────┼─────┤
│ e │ f │
└─────┴─────┘
Ideally this would be a new value for the existing style config key, keeping it backward-compatible:
require('render-markdown').setup({
pipe_table = {
style = 'full_grid', -- new option: separators between every row
},
})
Describe alternatives you've considered
- Pandoc Grid Table format (
+---+---+ syntax) — natively has per-row borders, but requires changing the Markdown source format and breaks GFM compatibility (GitHub, Obsidian, etc.).
- Manually inserting
| --- | --- | rows between every data row — works visually with the current renderer, but pollutes the source file and produces incorrect output on GitHub (extra delimiter rows rendered as data).
- Custom
nvim_buf_set_extmark script — possible but requires significant DIY Lua work that most users won't attempt, and arguably belongs in the plugin itself.
None of these are satisfying solutions for users who want to keep standard pipe table syntax while gaining better visual row separation.
Additional information
This is particularly useful for tables that contain:
- Wrapped long lines or inline code that spans visual rows
- Links rendered with icons/extra characters (which can shift perceived row height)
- Any content where the eye struggles to track rows horizontally across columns
The feature would reuse the existing border characters (├, ┼, ┤, ─) already defined in the config, so no additional character configuration should be needed. A virtual-text–based implementation (similar to how top/bottom borders are already drawn) should make this feasible without modifying the underlying Markdown source.
Is your feature request related to a problem? Please describe.
Currently,
render-markdown.nvimrenders pipe tables with only a single separator line below the header row:When cells contain multi-line content (wrapped links,
<br>, long inline code), it becomes very hard to tell where one row ends and the next begins without a visual divider between every data row.Describe the solution you'd like
Describe the solution you'd like
A
"full_grid"style option (e.g.style = 'full_grid'underpipe_table) that renders a├─────┼─────┤separator between every row, not just below the header:Ideally this would be a new value for the existing
styleconfig key, keeping it backward-compatible:Describe alternatives you've considered
+---+---+syntax) — natively has per-row borders, but requires changing the Markdown source format and breaks GFM compatibility (GitHub, Obsidian, etc.).| --- | --- |rows between every data row — works visually with the current renderer, but pollutes the source file and produces incorrect output on GitHub (extra delimiter rows rendered as data).nvim_buf_set_extmarkscript — possible but requires significant DIY Lua work that most users won't attempt, and arguably belongs in the plugin itself.None of these are satisfying solutions for users who want to keep standard pipe table syntax while gaining better visual row separation.
Additional information
This is particularly useful for tables that contain:
The feature would reuse the existing
bordercharacters (├,┼,┤,─) already defined in the config, so no additional character configuration should be needed. A virtual-text–based implementation (similar to how top/bottom borders are already drawn) should make this feasible without modifying the underlying Markdown source.