Support for spanning columns and rows?

[tpthian]

Hi @dhruvasagar ,

It's wonderful to have your plugin to VIM. I'm trying to work on the spanning multiple rows and columns via vim-table-mode. So far, I haven't been able to achieve that. I tried to look for online help but to no avail. Would you mind sharing how I can do that?

This is what I want to achieve:

TABLE 1:
+------------+------------+-----------+
| Header 1   | Header 2   | Header 3  |
+============+============+===========+
| body row 1 | column 2   | column 3  |
+------------+------------+-----------+
| body row 2 | Cells may span columns.|
+------------+------------+-----------+
| body row 3 | Cells may  | - Cells   |
+------------+ span rows. | - contain |
| body row 4 |            | - blocks. |
+------------+------------+-----------+

And yet this is what I get

TABLE 2:
+------------+-------------------------+----------+
| Header 1   | Header 2                | Header 3 |
+============+=========================+==========+
| body row 1 | column 2                | column 3 |
+------------+-------------------------+----------+
| body row 2 | Cells may span columns. |
+------------+-------------------------+----------+
| body row 3 | Cells may               | - Cells  |
+------------+ span rows. | - contain |
| body row 4 |  | - blocks. |
+------------+--+-----------+

I copied and pasted the above TABLE 1 into vim with Table Mode Enabled, it rendered well. Only until I moved the cursor inside the table, did it start to automatically rearranged every cells till it became TABLE 2.

I really appreciate your work and hope you can help me with this issue.

Regards,
JP

[leycec]

Seconded. Much to my disappointed face, I just hit this as well. 😞

For completeness, it should be noted that the above syntax is the grid layout variant for table syntax supported by reStructuredText (reST). Although reST also supports a simpler Markdown-style variant, the clearly superior grid layout renders that mostly irrelevant, so let's safely ignore that.

Sadly, this long-standing issue makes editing reST tables with row- or column-spanning cells more cumbersome than it should be. It's not a deal breaker per say; it's just an insufferable pain point that I suffer while grinding teeth with a white-knuckle keyboard grip. My current workflow resembles:

1. Enter Table Mode.
2. Allow plugin to mangle table cells while I sigh forlornly.
3. Manually rearrange table cells until they stop juggling themselves.
4. Perform desired table edits.
5. Exit Table Mode.
6. Manually remove inner table cell borders to respan row- or column-spanning cells.
7. Sigh forlornly yet again.

Quite simply, it sucketh.

Vanilla non-grid Markdown table support is, by compare, significantly more robust – probably because vanilla non-grid Markdown tables don't even support row- or column-spanning cells. It'd be nice if Table Mode wasn't quite so assertive for reST buffers, but... code beggars can't be choosers, eh?

Thanks for all the awesome Vim volunteerism nonetheless, @dhruvasagar!

[dhruvasagar]

While I complete agree for the need for such behavior, it's not easily achievable.
There have been approaches proposed such as using |>2 or || for the table separator to indicate how many columns a cell should span which I like but I haven't yet been able to prioritize on building a working solution yet. Would like to hear your opinions on this too.

[leycec]

Hey, no worries whatsoever. I'm just delighted that you're willing to actively maintain this absurdly essential plugin on behalf of the community at large. Multi-cell support would just be the useful optional cherry icing on the cake that we can technically do without, because we currently are.

Let's talk syntax, though – because syntax is fun, kids! My preferred solution would be for implicit detection: that is, for the plugin to parse user-defined grid layouts with pure Vimscript and do its utmost best to preserve well-formed row- and column-spanning cells as is. Since Vimscript is hell, that probably doesn't sound very fun... and I'd agree. Since you propose plugin-specific syntax, there are probably very good (albeit undocumented) reasons why implicit detection is a no-go.

I'm not quite sure how plugin-specific syntax like |>2 would jive with Markdown or reST, but... that seems a disastrous recipe for syntactic conflicts. Ideally, the plugin should introduce as little new syntax as possible. Is this possible? I am clueless (and thankfully not the maintainer of this plugin).

Thanks for all your tremendous efforts here, @dhruvasagar! You amaze and stun the expectant crowds with your open-source volunteerism. 👍

[dhruvasagar]

Thanks for your kind words. And you're absolutely spot on with regards to syntax and compatibility issues that may ensue as a result of trying to implement something like this. That has been the no. 1 concern of mine and why I haven't given it much thought. I would much rather invest my time into building other essential functionality improving the experience of editing & manipulating tables in general.

[void-m4110c]

Hi,
is there any plan to implement this behavior in the near future?
What should we expect as a rough timeframe for when this will be available?
Thanks in advance!

[dhruvasagar]

@void-m4110c So far I haven't encountered / thought about a clean way to implement this. So we're stuck at that. I haven't come across something like this elsewhere for reference. So for now there's no timeline when this will be available.

[dlcotter]

nthing the usefulness of this feature (and WHAT A GREAT PLUGIN!)

[dhruvasagar]

As an update, in my ongoing efforts to improve the plugin I am trying to borrow ideas from emacs' table mode, they have solved most of these requirements, although not all behaviors are easily portable from emacs over to vim.