coverage html does not generate nice tables

[nedbat]

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.

---

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/491

[nedbat]

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:

1. If tables are deemed definitively better, use them instead.
2. If it's deemed worth the extra effort/complexity, add an option to generate file reports as tables
3. Develop a custom css file that you can apply to reports that hides the numbers

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 .

[nedbat]

Original comment by Benjamen Meyer (Bitbucket: BenjamenMeyer, GitHub: BenjamenMeyer)

---

The solution, IMHO, is that the tables should be generated as:
rowcolumncolumnend row
instead of

columnrow...end columncolumnrow...end column
While the HTML is valid, it is an incorrect use of tables that will only ever lead to problems, including the many issues regarding alignment.By changing to doing what I suggest above, then the whole issue regarding alignment goes away as the tables will naturally solve that problem.
Ben

[nedbat]

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.

[nedbat]

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 ?

[nedbat]

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

[nedbat]

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).

[nedbat]

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?

[nedbat]

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.

[nedbat]

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.
If you want to reproduce - you can use my branch - https://github.com/BenjamenMeyer/falcon.git - which I just used to check this with a fresh "pip install coverage". I modified the "tox.ini" to stop from moving the coverage data to another directory.
$ source env/bin/activate   <- to activate the environment to run tox$ tox -e py27$ coverage html$ cd htmlcov$ lynx index.htmlSelect "falcon/util/uri.py"

[nedbat]

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.

[nedbat]

@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.

[nedbat]

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.
Ben

Sent from Yahoo Mail on Android

[nedbat]

@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".