Given
~ % nvim --version
NVIM v0.10.4
Build type: Release
LuaJIT 2.1.1736781742
tabular % git -P log -1
commit 12437cd1b53488e24936ec4b091c9324cafee311 (grafted, HEAD -> master, origin/master, origin/HEAD)
Author: Matt Wozniski <mwozniski@bloomberg.net>
Date: Wed Jul 3 12:03:37 2024 -0400
Fix duplicate :Tabularize tag in docs
vim-markdown % git -P log -1
commit 8f6cb3a6ca4e3b6bcda0730145a0b700f3481b51 (grafted, HEAD -> master, origin/master, origin/HEAD)
Author: Hiroshi Shirosaki <h.shirosaki@gmail.com>
Date: Fri Sep 20 15:23:57 2024 +0900
Merge pull request #636 from KSR-Yasuda/bugfix/CodeFenceHandling
Code fence handling breaks if `~~~` appears in the fence
The following simple source file:
| A | B | C |
|---|---|---|
| a | b | c |
if I position into the table and execute :TableFormat<CR>, the table is transformed as such:
| A | B | C |
|---|---|---|
| a | b | c |
subsequent executions of TableFormat results in additional prefix whitespace. 4 executions in total adds 4 whitespace, which is problematic because 4 prefixing whitespace is the indentation for a code block:
| A | B | C |
|---|---|---|
| a | b | c |and will be rendered broken:
| A | B | C |
|---|---|---|
| a | b | c |
If alignment characters are used in the header row separator, the situation is much worse:
| A | B | C |
|:--|:-:|--:|
| a | b | c |
after 1 application:
| A | B | C |
|:---|:---:|---:|
| a | b | c |
after 2 applications:
| A | B | C |
|:---|:---:|---:|
| a | b | c |
(subsequent applications will only increase the prefix whitespace and no longer change the table itself).
Given
The following simple source file:
if I position into the table and execute
:TableFormat<CR>, the table is transformed as such:subsequent executions of
TableFormatresults in additional prefix whitespace. 4 executions in total adds 4 whitespace, which is problematic because 4 prefixing whitespace is the indentation for a code block:and will be rendered broken:
If alignment characters are used in the header row separator, the situation is much worse:
after 1 application:
after 2 applications:
(subsequent applications will only increase the prefix whitespace and no longer change the table itself).