-
-
Notifications
You must be signed in to change notification settings - Fork 448
coverage html does not generate nice tables #491
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
Comments
Original comment by Matthew Boehm (Bitbucket: mattboehm, GitHub: mattboehm) While coverage generates its own HTML, I've run into this same thing with pygments. Pygments allows you to choose whether or not you want a table. It defaults to not using a table so that you can copy source code without copying line numbers. A few possible resolutions:
Since this bug seems specific to lynx. I'd recommend that we explore option #3 so that no changes to coverage are needed. You can read about how to include custom css to your html reports at https://coverage.readthedocs.io/en/coverage-4.1/cmd.html#html-annotation . |
Original comment by Benjamen Meyer (Bitbucket: BenjamenMeyer, GitHub: BenjamenMeyer) The solution, IMHO, is that the tables should be generated as: columnrow...end columncolumnrow...end column |
Original comment by Benjamen Meyer (Bitbucket: BenjamenMeyer, GitHub: BenjamenMeyer) @mattboehm while Lynx may exhibit the behavior best, it is not specific to Lynx, but any browser that doesn't necessarily apply CSS. Per specific detail, my issue is with how poorly coverage generates the row data, choosing a rather obtuse manner to do so instead of a simpler format that would be guaranteed to render better on all browsers regardless of CSS support. There is also no reason why CSS support should be necessary to implement a simple table. CSS should augment the table to add styles, not make it correctly render at its most basic level - getting columns and rows aligned. If you do the simple: ...Then nearly all if not all html renderers will generate the correct page even if CSS is not applied. However, for some obtuse reason coverage is generating: ...And that will cause problems, and also lead to the various rendering bugs since CSS is now required to try to get the columns to line up properly. |
Original comment by Loic Dachary (Bitbucket: dachary, GitHub: dachary) @BenjamenMeyer could you please describe a way to reproduce the problem ? I tried and do not observe the obtuse ... you're mentionning. By code page I assume you mean the page that displays the python code being covered. But maybe not ? |
Original comment by Benjamen Meyer (Bitbucket: BenjamenMeyer, GitHub: BenjamenMeyer) I will try to find some time to reproduce again. It's been a while; but it was very reliable at the time. May be something changed since that fixed it.... |
Ben is right about the structure of the file, but has mis-remembered the tags. As the code sample above shows, the source is a table with a single row and two cells. The first cell has all the line numbers (in elements), the second cell has all the source lines (also in elements). |
Ben, I've just looked at the HTML output with lynx, and I see what you mean about the line numbers, but I also wonder if this is worth pursuing: so much is wrong with the display, I don't understand what you will get from it? Because CSS isn't interpreted, there's no indication of lines covered vs uncovered, there's no syntax coloring, and even the indentation of the code is lost and the lines are double-spaced. What information are you getting from these pages? |
BTW, links and elinks both display the table properly, though both still have the larger issue that without CSS, there's no useful information on the page. |
Original comment by Benjamen Meyer (Bitbucket: BenjamenMeyer, GitHub: BenjamenMeyer) I am not interested in pretty stuff; I'm interested in getting to the core functionality, and I think if you solve this you'll also solve other issues you have as a natural side effect. CSS shouldn't be necessary for loading the code coverage information. I checked one project - Falcon (https://github.com/falconry/falcon) - that I have worked on. Viewing the file in "links" I found the line 132 in "falcon/util/uri.py" that had 16 branch misses; I was able to find the same text while looking at the data under "lynx"; however, the table structure kept the line information from coming up. |
Original comment by Benjamen Meyer (Bitbucket: BenjamenMeyer, GitHub: BenjamenMeyer) Okay...just looked at the HTML; I think it changed since I originally looked at it. Either way, each source line should match up to a single row in the table, with each column containing the various information - line number, source, comments, etc. This will solve formatting bugs - like text alignment, text sizes, etc. |
@BenjamenMeyer I don't understand how you are seeing which lines are covered and which are not? The HTML report only shows that by coloring the lines differently. Maybe I'm forgetting something about the information in the report, but I couldn't see the information when I checked a report in any of the character-mode browsers. |
Original comment by Benjamen Meyer (Bitbucket: BenjamenMeyer, GitHub: BenjamenMeyer) You click on the file listing and see the source code. The first line where an issue occurs will have a notation. It might be a separate html paragraph (p element). If rendered correctly it is to the left of the source line IIRC. Sent from Yahoo Mail on Android |
@BenjamenMeyer I see what you mean: partial branches show a paragraph with a notation about why the branch is partial. But there is no indication about completely uncovered lines. This report is unusable in a text-based browser, for more reasons than just the alignment of line numbers and lines. I recommend using one of the text-based reporting methods, either "coverage annotate" or "coverage report -m". |
Originally reported by Benjamen Meyer (Bitbucket: BenjamenMeyer, GitHub: BenjamenMeyer)
I primarily develop on a remote server accessible over SSH. So I use lynx to view coverage reports. When I view the index.html everything looks fine; however, when I look at any individual file I get a listing of all the line numbers then a listing of all the source lines.
Looking at the generated HTML, the index.html works because it builds each table row with all the information in it. However, the code pages seem to generate two blocks of data which I would not necessarily expect to line up properly.
I've noticed a few other Issues reporting alignment issues with the line numbers and code and this would seem to resolve those as well; I'm not sure this is a duplicate issue of any of those but the solution here would seem to address them - that is, make the code pages generate the same kind of data as the index page does - each line having all the data for that row.
FWIW, this makes the coverage reports very hard to follow in browsers like lynx.
Note: I did check the "links" console web-browser and things work there. I'm not sure what the difference is, but either way the above should make it more reliable across all browsers.
The text was updated successfully, but these errors were encountered: