Bug#854249: RFS: coloredlogs/5.2-1 [ITP]

[Adam Borowski <kilobyte@angband.pl>]

Control: tags -1 +moreinfo

On Sun, Feb 05, 2017 at 06:20:50PM +0530, Gaurav Juvekar wrote:
> I am looking for a sponsor for my package "coloredlogs"
> 
> * URL             : https://coloredlogs.readthedocs.io
> 
> It builds these binary packages:
> 
> coloredlogs - Convert colored logs with ANSI escape sequences to HTML files.
> python-coloredlogs - Colored terminal output for the logging module in Python2
> python3-coloredlogs - Colored terminal output for the logging module in Python3
> 
>    dget -x https://mentors.debian.net/debian/pool/main/c/coloredlogs/coloredlogs_5.2-1.dsc
> 
> This is the initial packaging for the original RFS.
> The dependencies also have open RFS at #852233 and #854115.

Hi!
I see your package provides two nearly completely independent pieces of
functionality:

* (as solely mentioned in the ITP): formatting Python logs and routing them
  either to syslog or a terminal, in the second case there's some very
  minimal coloring -- a whole line gets a color applied based on log level.
* (the actual main package): takes an arbitrary ANSI-colored log and
  converts it to HTML

I have no issues with the first part (aka python{,3}-coloredlogs) --
marking up important pieces of a log greatly improves readability.

However, the second part, converting logs to HTML, is not only redundant
with ansi2html (package colorized-logs, split out from kbtin) and aha, but
also too simplicistic and buggy to do its job.

Your implementation supports only a very minor portion of possible SGR
codes.  That's good on output (works on even crappiest terminals), but not
when it's you who's supposed to accept arbitrary input, especially
considering that the conversion target can render everything except for
<blink>/text-decoration:blink (removed from every browser).  And, even for
that limited subset, your parsing is buggy.


Here's a primer on the syntax:
SGR, and most other ANSI sequences, have the form of:
    \e [ PARAMETERS C
where C is a command type ("m" for SGR), and PARAMETERS is a semicolon
separated series of one or more positive integers.  These integers can be
prefixed by an arbitrary number of zeroes (old versions of curses for
example liked "00" and "01"); an empty string means 0.

For SGR, commands are independent, thus \e[1;2m is a shorthand for
\e[1m\e[2m -- except for poorly-designed 256/24-bit color codes that take a
series of 3-6 numbers, so you need to understand them to be able even to
properly ignore.  If you don't, they'll turn on blink (256-color) or dim
(24-bit) then issue a random unrelated command.

I won't list the commands here, Wikipedia has a good list, although it lists
rare xtermese "double underline" for 21 rather than "turn off bold/bright"
that most terminals implement.

Almost no sequences other than SGR make sense in a hardcopy text such as a
log; I've seen \e[C in the wild to compress a string of spaces.


I think it'd be best if you dropped the "coloredlogs" binary and left just
the python logging libraries; the alternative would involve reimplementing
it basically from scratch.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11