<commit_before>Cuv'ner
=======

"A commanding view of your test-coverage"

The command-line tool ``cuv`` provided by this package gives some
useful tools to visualize your project's coverage data. This means you
must first run `coverage`_ against your project's test-suite.

Once you have a ``.coverage`` file, you can use the commands
documented below (or just type ``cuv`` to explore the help).

We utilize several quality open-source packages to achieve this:

 - `coverage`_ by <NAME>
 - `Click`_ by <NAME>
 - `pygments`_
 - `ansicolors`_
 - `Pillow`_
 - `svgwrite`_
 - `Source Code Pro`_: the best programming font

.. image:: ../screenshots/cuvner-graph-twisted.png
    :alt: console graph, showing Twisted code

.. image:: ../screenshots/cuvner-lessopen-twisted.png
    :alt: pygments + coverage coloring in console

.. image:: ../screenshots/cuvner-histogram-twisted.png
    :alt: histogram view, Twisted code

Code: https://github.com/meejah/cuvner
Docs: https://cuvner.readthedocs.org

Background + Terminology
------------------------

This started out as some experiments in "whole-project coverage
visualization", and then also grew some console tools that I find
useful when working with Python code. There are a few hack-job
proof-of-concept visualizations in the works as well.

Modern MacBooks have resolution up to 2880x1800, and 4k displays can
be something like 3840x2160 -- I thought it might be interesting to
try and view the coverage of a "whole project at once". Some of these
experiments can be seen with ``cuv pixel``.

Whenever I say "line", I mean a "statement" as defined by coverage.py
-- this just means we ignore all comments and other non-code lines in
the visualizations. So, each file will usually appear to have far
fewer total lines than if you ran ``wc`` or ``ohcount`` against it.

Although I've done some code-cleanups and rudimentary testing, this
"works for me" but might not "work for your setup" ;)

As far as my setup, I am using Debian with a 256-color and unicode
capable shell using Solarized Dark color schemes. There are probably
bugs with other setups, and to a reasonable extent I'm happy to accept<commit_msg>fix attributions<commit_after>Cuv'ner
=======

"A commanding view of your test-coverage"

The command-line tool ``cuv`` provided by this package gives some
useful tools to visualize your project's coverage data. This means you
must first run `coverage`_ against your project's test-suite.

Once you have a ``.coverage`` file, you can use the commands
documented below (or just type ``cuv`` to explore the help).

We utilize several quality open-source packages to achieve this:

 - `coverage`_ by <NAME>
 - `Click`_ by <NAME> / pocoo
 - `pygments`_ by <NAME> / pocoo
 - `ansicolors`_ by <NAME>
 - `unidiff`_ by <NAME>
 - `Source Code Pro`_: the best programming font

.. image:: ../screenshots/cuvner-graph-twisted.png
    :alt: console graph, showing Twisted code

.. image:: ../screenshots/cuvner-lessopen-twisted.png
    :alt: pygments + coverage coloring in console

.. image:: ../screenshots/cuvner-histogram-twisted.png
    :alt: histogram view, Twisted code

Code: https://github.com/meejah/cuvner
Docs: https://cuvner.readthedocs.org


Background + Terminology
------------------------

This started out as some experiments in "whole-project coverage
visualization", and then also grew some console tools that I find
useful when working with Python code. There are a few hack-job
proof-of-concept visualizations in the works as well.

Modern MacBooks have resolution up to 2880x1800, and 4k displays can
be something like 3840x2160 -- I thought it might be interesting to
try and view the coverage of a "whole project at once". Some of these
experiments can be seen with ``cuv pixel``.

Whenever I say "line", I mean a "statement" as defined by coverage.py
-- this just means we ignore all comments and other non-code lines in
the visualizations. So, each file will usually appear to have far
fewer total lines than if you ran ``wc`` or ``ohcount`` against it.

Although I've done some code-cleanups and rudimentary testing, this
"works for me" but might not "work for your setup" ;)

As far as my setup, I am using Debian with a 256-color and unicode
capable shell using Solarized Dark color schemes. There are probably
bugs with other setups, and to a reasonable extent I'm happy to accept
{'fraction_non_alphanumeric': 0.09330582301696469, 'fraction_numerical': 0.009170105456212746, 'mean_word_length': 3.8967452300785634, 'pattern_counts': {'":': 0, '<': 10, '<?xml version=': 0, '>': 10, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1300824', 'n_tokens_mistral': 1325, 'n_tokens_neox': 1225, 'n_words': 599}