Follow-up to #410, which gave the github format alignment colons in separator rows by aliasing it to pipe.

This PR fixes a second inconsistency in pipe that #410 inherited: separator rows ignore the format's declared padding.

Problem

The pipe and github formats declare padding=1. Data rows honour this: _pad_row adds a space on each side of cell content. Separator rows do not: _pipe_segment_with_colons fills the full padded width with dashes, swallowing the padding positions.

| item   |     qty |
|:-------|--------:|    <-- no spaces after | or before |
| spam   | 41.9999 |
| eggs   |     451 |

The separator row is the only place in the table where padding=1 is silently ignored.

Fix

After this change, separator rows respect the format's padding, consistent with data rows:

| item   |     qty |
| :----- | ------: |    <-- spaces at padding positions, like data rows
| spam   | 41.9999 |
| eggs   |     451 |

Column widths are preserved: two padding spaces replace two dashes, keeping each segment the same total width.

The implementation adds a padding parameter to _pipe_segment_with_colons. When non-zero, it places spaces at the padding positions instead of filling them with dashes:

The padding parameter flows through the existing call chain:

1. _format_table already has pad = fmt.padding.
2. _append_line and _build_line now accept an optional padding keyword and forward it to callable line formats.
3. _pipe_line_with_colons passes it to _pipe_segment_with_colons.

Other callable line formats (_grid_line_with_colons, _html_begin_table_without_header, _latex_line_begin_tabular, _asciidoc_row) accept **kwargs for forward compatibility but do not use the parameter, so their output is unchanged.

Custom padding=0 formats are unaffected

The custom TableFormat with padding=0 shown in #195 (comment) is not affected by this change. That example uses non-callable Line objects (not _pipe_line_with_colons), so _build_line takes the else branch which is untouched. And with padding=0, the _pipe_segment_with_colons path produces zero-width padding strings, which is a no-op.

Original example from @astanin still produces the exact same output:

>>> import tabulate as t
>>> t.MIN_PADDING = 0
>>> github_nopadding = t.TableFormat(
...     lineabove=t.Line("|", "-", "|", "|"),
...     linebelowheader=t.Line("|", "-", "|", "|"),
...     linebetweenrows=None,
...     linebelow=None,
...     headerrow=t.DataRow("|", "|", "|"),
...     datarow=t.DataRow("|", "|", "|"),
...     padding=0,
...     with_header_hide=["lineabove"],
... )
>>> print(t.tabulate([[1,22],[33,4]], headers=["aa","bb"], tablefmt=github_nopadding))
|aa|bb|
|--|--|
| 1|22|
|33| 4|

Discovery context

I found this while investigating an infinite formatting cycle in click-extra between two CI jobs: one regenerates a markdown table using tabulate with tablefmt="github", the other normalizes markdown files with mdformat. Each run undid the other's output on the separator row: tabulate produced |:---|, mdformat normalized it to | :-- |, and the cycle repeated.

The concrete fight is visible in https://github.com/kdeldycke/click-extra/pull/1603/changes#diff-21283f808de8251aeb373ddd7d30d906afbb0f4dfe168733afb14f7ae6137984 (table regeneration strips spaces) and https://github.com/kdeldycke/click-extra/pull/1611/changes#diff-21283f808de8251aeb373ddd7d30d906afbb0f4dfe168733afb14f7ae6137984 (mdformat re-adds them), both touching docs/pygments.md.

Neither tool was wrong: GFM accepts both forms. The root cause was that tabulate's pipe format declared padding=1 but only honoured it for data rows. With this fix, tabulate's output already matches what GFM normalizers expect, so the cycle stops.

History

This is the second half of a fix I started in 2023:

• Renders GitHub-Flavored Markdown tables in canonical format #260 addressed both alignment colons and separator padding. Closed in favour of Add support for alignments in Markdown tables #261.
• Add support for alignments in Markdown tables #261 carried the alignment colon fix but was closed when the maintainer thought Add table format "colon_grid" #341 already covered it.
• Fix alignments in github tables #410 finally landed the alignment colon fix by aliasing github to pipe. Merged 2026-03-05, after the v0.10.0 tag.

#410 solved the alignment colon problem but did not address the padding inconsistency in separator rows, because the pipe format itself had the same behaviour. This PR completes the chain by making separator rows respect the format's declared padding, just like data rows already do.