boxes/helper: Add support for rendering tables.

[preetmishra]

I have added a helper function, render_table, to process a table and return its content as a list of strings which can then be rendered in the MessageBox and amended the test.

This implementation is v1. Feedbacks are welcomed. :)
There can certainly be follow-ups to improve this further.

Partially fixes #452.

@neiljp

[zulipbot]

Hello @preetmishra, it seems like you have referenced #452 in your pull request description, but you have not referenced them in your commit message description(s). When you reference an issue in a commit message, it automatically closes the corresponding issue when the commit is merged.

Please run git commit --amend in your command line client to amend your commit message description with Fixes #452..

An example of a correctly-formatted commit:

commit fabd5e450374c8dde65ec35f02140383940fe146
Author: zulipbot
Date:   Sat Mar 18 13:42:40 2017 -0700

    pull requests: Check PR commits reference when issue is referenced.

    Fixes #51.

Thank you for your contributions to Zulip!

[kaustubh-nair]

@preetmishra This is a great feature to have 🎉
I've tested this locally a little bit, and it seems to work well.

It would be useful to be able to support the syntax used by the web-app
If I use the example given here, I run into an IndexError exception.

[preetmishra]

@kaustubh-nair Thanks for the review. 👍 I have sorted out the bug that you found.

[preetmishra]

Another thing I have noticed is that in-table styling doesn't work in ZT yet (for instance, alignment). I was thinking that we might want to support that in v2 but if it doesn't seem like a good idea, I would move ahead to support that in v1 itself.

[neiljp]

@preetmishra This is rather good in use for a v1, though I've not dug into the code in depth 👍

Some thoughts:

• The table-like view is clean - you can see each cell - but could we get away with fewer horizontal lines? Then we can see more message lines in the message list at once (v1)
• More tricky, but if the screen is narrow then it breaks up quite badly (v2+)
• We could at least use box-drawing characters for the table to make it look tidier? (v1?)
• Potentially we could use a LineBox, to make some of that easier (v2+)
• Perhaps split the code into a html->internal and an internal->urwid (render) function?

If alignment is not tricky, it could be v1, but getting a good basic layout would be a great start; for example, we have bugs with quoting, but it works better than not knowing it's a quote, or not rendering it at all!

[preetmishra]

@neiljp Thanks for the review. I have made the changes that you suggested for v1.

I have:

• Removed all the horizontal lines (except the top, middle and bottom border).
• Used Unicode characters for drawing the table which makes it cleaner overall.
• Added support for alignments.
• Refactored the code quite a bit (including splitting the previous render function into two - parse_html_table and render_table).

I have left comments in the code for explaining a few points, let me know if it is too much or if we need more. :)

[neiljp]

@preetmishra This renders really well, and I love the improvements 👍

I think you could improve the test coverage for the new features/adjustments you made, and there is a small rendering nuance which makes this look a little off due to the way that the bold is applied.

I've done a first pass of the code, which works well as it is but might benefit from some minor improvements to improve the readability or style.

[preetmishra]

@neiljp Thanks. I have added extra test cases (to support different alignments), fixed the styling issue and incorporated the other changes that you suggested.

I have restructured the row styling functions to return a list of strings and tuples (style, string). This not only helps in centralizing the padding routine but also helps in setting styles individually. In addition to these, this also makes the work required for adding inline-table-styles in v2 rather straightforward.

I would add the tests for the helper functions once we reach a consensus about the implementation.

[preetmishra]

Update: Extended the docstring for pad_row_strip.

[neiljp]

@preetmishra Looking good 👍

I wouldn't worry about adding tests for the really intermediate functions - we can do, but they are implementation details for render_table. One alternative would be to keep the table tests for soup2markup separately as a test for that function. We can discuss.

Could you comment on the need for the first commit?

If we can clarify the conflicts with other PRs, I'd be quite happy to move the MessageBox into a separate file (and tests too?), and then all of this new work too, as we discussed on the stream - @sumanthvrao Did you try zulip/TinglingGit in the end?

[sumanthvrao]

@neiljp This is the TinglingGit Output for All the PR's which clash with the file ui_tools/boxes.py
and their diff

PR#397(+2-0)
PR#530(+4-0)
PR#278(+16-8)
PR#539(+1-1)
PR#540(+63-22)
PR#542(+26-18)
PR#287(+51-1)
PR#424(+8-1)
PR#572(+38-38)
PR#573(+11-10)
PR#335(+18-10)
PR#354(+2-0)
PR#550(+4-3)
PR#359(+12-1)
PR#371(+21-15)
PR#501(+6-2)

[preetmishra]

@neiljp Thanks. I have:

• Added a comment for the first commit (it lets row_with_styled_content add None display attribute).
• Added a few more test cases for the table.
• Replaced TABLE_ROW with StyledTableData as it seemed more reasonable. On a related note, urwid_Size type alias uses underscore with CamelCase, was this intentional or should we refactor?
• The vertical_bar is now a function argument for row_with_styled_content. This would make replacing box-drawing characters easy if we ever feel like to.
• Added comments for the type: ignore issues. I tried using a type: str for fill but it didn't seem to work.

If it is not much of an overhead, we can move the MessageBox in a separate file along with the new changes and perhaps separate the table test from soup2mark tests (thoughts?).

[neiljp]

@preetmishra This is looking great :)

Re urwid_Size I purposely chose this since this is intended to represent a type which should be externally defined. We could potentially handle this differently by providing type hints for urwid.

We should be able to fix at least some of the type ignores; the variable one we can leave - though it may be worth researching if it is a mypy issue.

[neiljp]

I tried to fix this myself just now. This works for hard-coded indices via eg. assert isinstance(row_strip[0], str) (so should work for the first and last element), but not where using a variable index. This is a case where the 'contract' for the function actually requires the '_char' ones to be unstyled, right? So, these assert statements enforce that, and mypy can confirm this :)

That it doesn't work with a variable could just be a mypy bug - worth checking, and that can be referenced in the ignore (as done in the main zulip/zulip repo, if you git grep for ignores)

[preetmishra]

@neiljp Thanks. I understand the idea for urwid_Size now.

I was able to fix all the mypy issues using cast, which assists mypy with the type, and what you suggested in #550 (comment) 👍.

[neiljp]

@preetmishra As I mentioned on the stream, this is now merged with a few minor tweaks 🎉 This is really great :) I'm sure you can find it in the list of commits by now!

[preetmishra]

@neiljp Thanks so much, it was fun working on this. :)

To address the things that we would like to see in the future iterations, I'll file an issue.