>> 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 _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
