[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Lyndon Nerenberg
Subject: Re: [Nmh-workers] colorized/highlighted scan output?
Date: Fri, 2 Nov 2012 22:14:19 -0700

On 2012-11-02, at 14:55 PM, Earl Hood wrote:

> Pretty much every modern terminal (emulator) supports color, so more
> power to those that want to do add color to scan output.

But is it worth the added code complexity?  What's bugging me the most about 
this proposal is that there is a solution being thrown forth without any real 
definitive description of the problem that needs solving.  Is there perhaps a 
better solution?  One that is useful in more contexts than just scan?

This group seems to be falling into a pattern of implementing every single idea 
anyone throws out, without any thought being given to the underlying need to 
add new core functionality vs. individuals adding personal customizations to 
their own environments via scripting the existing interfaces.  (When it comes 
to manipulating text, there's not much you can't do in not-too-many lines of 
awk.)  Just as importantly, little consideration seems to be given to the 
impact of these changes on the overall environment.  Changing the formatting 
code means messing around in a chunk of complex code that lies at the core of 
many of the tools.  The recent mailing list conversations make it abundantly 
clear that nobody understands the implications of adding variable-length 
sequences of non-printing bytes to the output buffers, and that tells me that 
nobody has taken the time to understand the real underlying problem (if there 
even is one to begin with).  But the popular refrain is 'If someone wants to 
code it, let them. Where's the harm?'

The harm is this leads to an ever cascading set of ill thought out "features" 
that bloat the code, "features" that are incompletely implemented, "features" 
that are not consistently implemented between the tools.  Ultimately, this 
leads to the "linuxization" of what was once a simple, elegant, and powerful 
tool set.

Writing code is easy.  Good software engineering is a lot harder, but the 
benefits are worth it.  The best lines of code are the ones you never had to 

Every programmer should be required by law to read Kernighan and Pike's seminal 
paper on this topic at least once per month.  Since we've just rolled into a 
new month, here's a little bit of weekend reading for everyone.


Attachment: unix_prog_design.pdf
Description: Adobe PDF document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]