-
-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Format Table
fails if <br>
occurs in header of pipe table
#959
Comments
Hmmm... I think the bigger problem here is that headers don't accept the same processing as body cells do for FWIW, if you have line breaks, formatting is likely not to work the way you'd expect with a Pipe table because it's based on the widest width of each row rather than the total width including the In general Pipe Tables are not meant to be used with line breaks - that's what Grid tables are for, but then some renders (notable GitHub) doesn't support Grid Tables. If you try to work with line breaks in pipe tables you'll have to live with the limitations of the format. So the actionable bug here is that it shouldn't break the table from rendering as valid markdown. |
Thank you for the improvements.
I assumed that "Pasting as PipeTable" means converting a grid table to pipe table by the Example: +--------------+-------+--------+-----+
| A | B | C<br>c | D |
+==============+=======+========+=====+
| L1 | line1 | 41<br> | yes |
| L1_cont1 | | 42 | |
| L1_cont2<br> | | | |
| L2<br> | | | |
| L3 | | | |
+--------------+-------+--------+-----+ Embedding the grid table above as pipe table results in the following: | A | B | C<br>c | D |
|------------------------------------------------|-----------------------|--------------------------|---------------------|
| L1<br>L1_cont1<br>L1_cont2<br><br>L2<br><br>L3 | line1<br><br><br><br> | 41<br><br>42<br><br><br> | yes<br><br><br><br> | Expected: | A | B | C<br>c | D |
|----------------------------------|-------|----------|-----|
| L1 L1_cont1 L1_cont2<br>L2<br>L3 | line1 | 41<br>42 | yes | Difference: I expected that normal line breaks are not replaced by Refinement: A non-trailing sequence of normal line breaks (2 or more) may be replaced by Embedding the pipe table above as grid table results in the following: +----------------------+-------+-----+-----+
| A | B | C
c | D |
+======================+=======+=====+=====+
| L1 L1_cont1 L1_cont2 | line1 | 41 | yes |
| L2 | | 42 | |
| L3 | | | |
+----------------------+-------+-----+-----+ Expected: +--------------------------+-------+--------+-----+
| A | B | C<br>c | D |
+==========================+=======+========+=====+
| L1 L1_cont1 L1_cont2<br> | line1 | 41<br> | yes |
| L2<br> | | 42 | |
| L3 | | | |
+--------------------------+-------+--------+-----+ Difference: I expected that |
Ok so I think I fixed the import and export for multi-line headers. Your first table actually imports now and retains its formatting for edit/paste and format table operations. The header parsing had a couple of issues:
Update is 2.5.7.3 deleted previous message where I misinterpreted what you are trying to do |
I repeated my two conversion tests (posted above) with mm v2.5.7.4. The second one (converting a pipe table to a grid table) is OK now, but the first one (converting a grid table to a pipe table) still fails. Here it is again: Input (grid table): +--------------+-------+--------+-----+
| A | B | C<br>c | D |
+==============+=======+========+=====+
| L1 | line1 | 41<br> | yes |
| L1_cont1 | | 42 | |
| L1_cont2<br> | | | |
| L2<br> | | | |
| L3 | | | |
+--------------+-------+--------+-----+ Actual Output (pipe table): | A | B | C<br>c | D |
|------------------------------------------------|-----------------------|--------------------------|---------------------|
| L1<br>L1_cont1<br>L1_cont2<br><br>L2<br><br>L3 | line1<br><br><br><br> | 41<br><br>42<br><br><br> | yes<br><br><br><br> | The Expected Output (pipe table): | A | B | C<br>c | D |
|----------------------------------|-------|----------|-----|
| L1 L1_cont1 L1_cont2<br>L2<br>L3 | line1 | 41<br>42 | yes | In principle a cell of a grid table can contain two kinds of line breaks, like a normal Markdown text, namely:
A single A sequence of two or more |
I don't consider this a bug although that does result in different behavior when moving between formats. The reason for this is that Pipe and Grid tables handle line breaks differently. Grid tables support both positional linebreaks (ie. just a display line break in the editor and in the markdown text) and physical line breaks ( Grid tables in the editor require that you use I don't see a way to consolidate this without losing functionality in grid table support. If I made grid tables behave like pipe tables I gain compatibility between the two, but it would potentially break formatting of the input table into the editor as an input table with breaks only would be misrepresented. Independently each of the formats behaves correctly. Converting between will produce differences in some cases. Going from pipe to grid will likely produce the correct results and if you're consistent in use of Converting between formats should be very rare - it's much more important the original formatting is maintained when creating/editing/formatting existing tables as much as possible IMHO. |
The
This doesn't make sense to me. I did not mention a word about consolidating the behavior of grid tables and pipe tables. |
Huh? I'm not talking about creating a single output option. Maybe you should re-read what I wrote. I'm talking about consolidating the edit features so that they produce the same output for grid and pipe tables, which is not possible due to the differences in the behavior of pipe and grid tables. The same exact table in the editor may produce different rendered output (and markdown behavior). Regardless of what is done there's no 1:1 relationship between the two in some special cases involving linebreaks. The expectation and most common use case is:
and that should preserve as much behavior as possible. I believe this works well for both table types. The behavior is predictable and works well for two-way conversions. The other use case is:
This works still as it did before. But here there's potential that the markdown generated will have different behaviors because of the format differences in the two formats. You can still convert - none of that has changed. But if you have line breaks in your tables the behavior might be different if you're using non |
I think we have a communication problem. Therefore I go back to square one and present a better example to show the following:
Typical Grid Table T1+----------------------------+-------+--------+-----+
| A | B | C<br>c | D |
+============================+=======+========+=====+
| Paragraph 1 | John | 41<br> | yes |
| containing a **forced line | Smith | 42<br> | |
| break** (`<br>`) here.<br> | | 43 | |
| Begin of new line. | | | |
| | | | |
| Paragraph 2. | | | |
+----------------------------+-------+--------+-----+ Pipe Table T2 converted from T1 by mmThe following pipe table T2 has been converted from grid table T1 by the | A | B | C<br>c | D |
|-------------------------------------------------------------------------------------------------------------------|-------------------------------|------------------------------------|-------------------------|
| Paragraph 1<br>containing a **forced line<br>break** (`<br>`) here.<br><br>Begin of new line.<br><br>Paragraph 2. | John<br>Smith<br><br><br><br> | 41<br><br>42<br><br>43<br><br><br> | yes<br><br><br><br><br> | Pipe Table T3 converted from T1 by new algorithmThe following pipe table T3 has been converted from grid table T1 by applying a few rules manually. | A | B | C<br>c | D |
|---------------------------------------------------------------------------------------------------------|------------|----------------|-----|
| Paragraph 1 containing a **forced line break** (`<br>`) here.<br>Begin of new line.<br><br>Paragraph 2. | John Smith | 41<br>42<br>43 | yes | Assessment
Do you still object? If yes, please explain concretely and concisely (backed by example). |
I understand what you're saying and I'm telling you that the conversion from grid to pipe table will never be perfect because there are different features in these two formats. There's a loss of fidelity going from Grid to Pipe. The reason you see these differences is because a choice has to be made how to handle the line breaks. Editor line breaks are handled differently depending on whether the mode is Grid or Pipe. In Pipe mode:
In Grid Mode
See the problem here? In Pipe the line breaks are translated into Editing and staying with the same format works because the import can account for the mode and make decisions about what line breaks and The way this needs to be fixed is for the the user to remove the Example in your table: In the header the Here's what manual removal looks like from your original table: which renders: This is an edge case at best. if you need to go back and forth it's reasonable enough to have to make small changes. |
I appreciate your taking time for this issue. Now the chances are good that I can clear the misunderstanding but you can rest assured that this is my last attempt to convince you. First I will briefly describe the terms and context as basis for my reworded and refined suggestion. Terms and ContextTo make the discussion easier I will use the following terms and notation:
The TE can be considered also as rudimentary Markdown renderer using an internal table format. Generally TE does the following:
BTW: The new Since TE supports multiple table formats ( Refined SuggestionIn my previous post I showed the conversion of a typical grid table T1 to the pipe tables T2 and T3, that is:
In the meantime I refined my suggestion and described it using regex. If the user changed the TE table format from
Of course the conversion from grid to pipe table cannot be perfect because information is lost in general. However the suggested conversion is much better than the current one. Related New SuggestionsThe behavior of TE in
This change goes hand in hand with the suggested converter but is not required. The behavior of TE in
The suggested preprocessing on embedding the table may also be executed as postprocessing on opening the table. Other Remarks
Edge case? I would say T1 is rather too simple than too complex for a grid table. Usually a grid table is chosen exactly because you have complex cells.
You should not underestimate these "small changes". Generally they are quite time-consuming and error-prone, especially if you have a real table instead of my little demo table. |
The command
Format Table
of mm 2.5.3 fails if<br>
occurs in the header of a pipe table.Example:
After applying
Format Table
command:Obviously
Format Table
treats<br>
as line break, although it is meant only for the renderer.Expected:
or (better):
BTW:
Format Table
works correctly if<br>
occurs in the header of a grid table, but unfortunately grid tables do not allow columns to be right-aligned or centered (Align Column...
is ignored instead of ghosted, but that is acceptable).Example:
After applying
Format Table
command:The text was updated successfully, but these errors were encountered: