DavidAnson
Proposal: One more parameter for MD060
I'd like to propose an extra parameter for MD060, which is something we already implement in our docs through https://marketplace.visualstudio.com/items?itemName=fcrespo82.markdown-table-formatter:
That formatting extension has the limitLastColumnLength setting, with an option called: Follow header row length, and the description is: Do not extend last column to more than the table's header row.
Essentially, what it means is "Align all columns except the last column":
Before:
| App name | Default status | Requirements |
|------------|----------------|------------------------------------------------------------------------------------------------------------------------------|
| App one | Enabled | None |
| App ten | Disabled | Use on Thursdays |
| App twenty | Enabled | If you are going to use this application, ensure you have fulfilled the prerequisites and can no longer use any other option |
After
| App name | Default status | Requirements |
|------------|----------------|--------------|
| App one | Enabled | None |
| App ten | Disabled | Use on Thursdays |
| App twenty | Enabled | If you are going to use this application, ensure you have fulfilled the prerequisites and can no longer use any other option |
This is a very common formatting issue with Markdown tables, as we often put descriptions, requirements, etc in the last column and they can vary drastically in length, causing a huge amount of additional padding.
It would be great if we could add one more parameter to the existing aligned / any / compact / tight. Maybe aligned-compact? Which aligns all columns, except the last which uses 1 space if it's longer than the header row?
I understand the issue and I considered something like this with the initial implementation. However, looking around for examples, it was pretty easy to find cases where it wasn't just the last column that needed special treatment. Sometimes it was the last two columns or maybe the first column has really long names sometimes. It didn't seem that there was a broadly applicable pattern, though I expect the last column is the most popular exceptional column as you show above.
Another issue (which I capture here largely for my own benefit now that I'm thinking about this again) is that rule configuration is done per project (or in extreme conditions per file) and there's nothing to say that every table in the project wants or needs its last column handled uniquely.
It would be ideal to be able to infer the need for this on a case-by-case basis. And although it might be straightforward to detect a table using this pattern and not report an issue for it, it may be difficult to detect a table NOT using this pattern that just happens to have a weird last column, etc. and recommending how to fix it could also be iffy.
@DavidAnson Hrm, I feel there's not much you can do if an internal column needs special treatment, either all columns are aligned, or not. If an internal column requires special treatment, everything else to the right of it would likely get misaligned if you didn't just do the whole table?
Thinking a bit more about it too, perhaps I should have called it a "less-padding" or "tight-padding" option, rather than alignment. Because all "internal" pipe characters are still aligned, it's just checking if there's extra padding at the end. This sort of matches the "no external pipes" or "open" format (I'm not sure what it's called). But if you use that format, you omit the leading and trailing pipes, which also means at no point is padding used in the last cell. So my idea would be to do the same, but with the outer pipes.
-
"open" style of a table I was looking at recently, auto-formatted by any formatting tool always gives this, with no padding in any row in the last column:
Tool | Language | Command | Regex pattern -----------|----------|----------------|--------------- pytest-cov | Python | `pytest --cov` | `/TOTAL.*? (100(?:\.0+)?\%\|[1-9]?\d(?:\.\d+)?\%)$/` Simplecov | Ruby | `rspec spec` | `/\(\d+.\d+\%\) covered/` -
Same table, but with the "tight-padding" style. Same as above, but with the pipes.
| Tool | Language | Command | Regex pattern | |------------|----------|----------------|---------------| | pytest-cov | Python | `pytest --cov` | `/TOTAL.*? (100(?:\.0+)?\%\|[1-9]?\d(?:\.\d+)?\%)$/` | | Simplecov | Ruby | `rspec spec` | `/\(\d+.\d+\%\) covered/` |
So perhaps adjust the proposal to be about limiting end-column padding?
This framing seems helpful, thanks! I'm still not sure I see how to distinguish your original example from being deliberate in your style vs. incorrect in the fully aligned style, so this capability seems to need to be an additional property on the rule that says something like "relaxed last column" (as you propose).
If the right-most cell of an aligned table with end pipes is longer than expected, require that cell to have the compact style instead.
I'll need to experiment with this to see if there are unexpected implications, but it seems like it might do the trick.
FYI, I came back to this issue recently with the intent to fix it, but couldn't come up with an approach I liked after a couple of days thought. One challenge is that if you want to allow the compact single-space format for the last column, you should also allow the tight style, so this option is more than a boolean. And per my comments earlier, it needs to be opt-in. Also, whatever it is should make sense (or at least not be silly) for people using compact or tight for the entire table.
But even after sorting those questions out, it's unclear what to do with something like the following:
| Heading | Heading |
| ------- | ------- |
| Text | Text |
| Text | Text text text text |
| Text | Text text text text text |
Does anyone really want to argue the second-to-last line should be reported as a violation? What's shown above seems truer to the aligned style than if the two long lines both ended compact. And surely the following table has a violation even though the proposed changes to this rule would not report one:
| Heading | Heading |
| ------- | ----------------------- |
| Text | Text |
| Text | Text text text text text |
Instead of jumping through hoops here, I feel like it makes sense for tables with funky last columns to simply delete the trailing pipe (and optionally the leading one) which leads to the following approach which is ALREADY valid today:
| Heading | Heading | Heading
| ------- | ------- | -------
| Text | Text | Text
| Text | Text | Text text text text
| Text | Text | Text text text text text