Re: [Nmh-workers] colorized/highlighted scan output?

[Ken Hornstein]

>> So what do others think?
>
>That this functionality in a command line tool is silly.  If you need a
>GUI, install exmh.

Well, I respectfully disagree.  If we replace "cyan" with "bold"
or "underline", we're talking about functionality that has been
used with VT100-compatible terminals for a long time.  Okay, how
that actually ends up happening has always been a bit weird; for
example, man outputs "bold" text by doing overstriking with ^H and
less knows how to deal; I don't know if that was planned as much
as it is an artifact of history.  But I don't see any logical
difference between hilighting the current message with bold or
inverse versus using cyan.  Now maybe it's just me, but I'm personally
not a fan of colorized ls; the default color scheme chosen has poor
contrast in my experience, and it ends up messing up the terminal
in a number of situations.  But I'd be happy with something that
could do bold or underline.

Oliver Kiddle writes:
>Multiplying maximum width by MB_CUR_MAX is one way to determine a
>suitable buffer size though that doesn't allow for escape seqences for
>colours. Is it too ugly to have the function allocate the buffer and
>rely on the caller to free it?

Memory management in the format code is terrible; I struggled with that
a lot when adding support for replyfilter.  Having fmt_scan() allocate the
buffer would make a lot more sense.  Cleaning that up was actually one of
my medium-term projects.

Kevin Costgrove writes:
>How do 'grep' and 'ls' do their color highlighting?  That seems 
>pretty portable across the systems I use.  Maybe there's something to 
>borrow from those?

I just looked; ls, at least, hardcodes the ANSI sequence strings
into the code (hm, so does grep).  I don't know if that's standard
practice or not; somehow doing that still sticks in my craw.  I will
note that scan and inc already link against termcap.

--Ken