Hi Matt,

I played around a bit with apt-listchanges and found that it'd be
really cool to have the output colorized. I wrote a small and simple
patch to do the job using regexps, it worked reasonably well on the
files I tried.

The patch enables color mode to the text and pager frontends, but note
that not all pagers support displaying raw control codes. In fact, I
found that `less' needs the `-r' or the `-R' switch, but `most' and
`more' don't support them in any ways. This situation could be handled
eg. by using a special configuration variable "pageropt", which would
hold a string that'd be passed to the pager at the invocation time,
but I haven't implemented it yet, as your opinione may vary.
Unfortunately it means that only `less' can be used as pager for color
output. Text output works without any such flaws if the terminal
supports ANSI color codes.

I haven't tested this whole thing with the xterm-pager frontend but I
assume that it works with the same conditions as the console pager.

I also updated the manual a bit, <option></option>-s were missing at a
few places and I documented the new feature added by this patch as well.

Please make permissions and owners in the upstream tarball a bit more
standard, if possible.

Regards,

This sounds interesting, though I haven't tried it yet.  The problem with
pager interaction is discouraging, as pager seems to be the most popular
frontend at the moment.  Most users probably don't want to have 'less' use
the -r or -R option by default, but only with apt-listchanges.  This means
that we could no longer use sensible-pager, and would have to invent a
secondary mechanism for specifying the pager program.

It would be great if your patch could use the terminfo database to get the
escape codes, rather than hard-coding them, so that it could correctly
support any terminal type.

Another option might be to use an HTML output frontend to do colorization
and hyperlinks (see wishlist bug #82360).  Then you wouldn't have to worry
about any of this.

It does.

Thanks for taking the time to document your changes.

Are you referring to group writability?  That is the default on many Debian
systems, and you'll find that it's not unusual in source tarballs if you
browse through the Debian archive.

The same goes for the ownership (mdz/mdz).

[...]

I agree. I myself use the pager frontend (with less) as well, but I
find colorization great, as it makes the changelogs more readable,
therefore I believe that it's worth having a bit of inconvenience in
favour of having this feature.

Yes. I can imagine two workarounds, but neither of these is perfect.

1) Examine if sensible-pager calls `less', and if yes, automatically
   invoke `less' as pager with the -r option, if not, then simply call
   sensible-pager with no colors.

2) Add a configuration variable to apt-listchanges which holds the
   options passed to sensible-pager. In this case, it'd be up to the
   user to tell apt-listchanges whether the pager can display colors
   and if yes, what options (if any) it needs.

I'll look into it if we can find a solution to incorporate the patch
into apt-listchanges (it's quite pointless otherwise :). You know,
this patch was a quick hack, but if you find it worth including, I'll
try to improve it (perhaps the regexps need to be fined a bit as well).

Well, this is an interesting idea, but I stick to the pager.

Ok, that's right, it just seemed first a bit odd to me.

Regards,

I must have completely overlooked the documentation fixes in your bug
report; I thought you were just adding documentation for the option you
added in your patch.  I've applied them in CVS now, thanks.

-- 
Best regards,

Brian T

I am unable to reproduce the fix that was mentioned in this bug.  I
tried with less and running `export LESS="-r $LESS" and
`export LESS="-R $LESS"`.

Marking as unreproducible for now.