lynx-dev when, where, why "kb/sec"? Any votes for a "simple" Lynx

[Nelson Henry Eric]

> Read 4 KB of data. 4 kb/sec.

Not fair for me to speak up at this stage of the game, but for
my Internet connection this kb/sec "feature" is superfluous
(usually sits at 0 kb/sec; got up to 2 kb/sec once, but that
was only because I was rocking in my chair encouraging things).
Is there anyway to compile for the old-stlye data counter?
Seeing the bytes click over is enough to know what the speed
of transfer is.

Finally having been able to compile a development version (22),
it seems as if a few other little changes like this have crept
in.  It would be a lot of work to do if done all at once, but
I wonder if we could establish a BARE_BONES symbol that would
be a kind of generic symbol to not compile in simple cosmetic
changes which add code, no matter how miniscule.  It might be
a way to rather painlessly slow down the creaping bloat of Lynx,
which is becoming a major problem.  It is a fact that the Lynx
image on my SunOS has grown *FIVE* times what it was a little
less than 3 years ago.  Having a generic symbol that anyone could
wrap their new code in might be convenient.  In the future, a few
other obvious chunks not yet under control of compile options
could be added on.

If there is any interest in this, I might start with the tiny
piece that I added to avoid the need for a separate lpansi
program.  The BARE_BONES (open for suggestions for a better
name!!) symbol would in this case remove the entire "case
TO_SCREEN" in printfile() and all other associated definitions
and code.  I would probably go ahead and tie in what I know
how to cut out easily, e.g., news.  In months to come I would
then slowly plug away at the many hints Klaus gave me in the
past (ca. Oct. 1997) about reducing the image size.

The advantage to this system, if you understand what I'm hinting
at, is that it would greatly reduce the complexity of the ifdefing
and would only require one generic message to pop up to explain
why the user couldn't reach the feature.  The disadvantage would
be that it would be all or nothing, i.e., you couldn't pick and
choose among the many tiny features that would be knocked out.  An
example of where this might really bug people would be that I'd
probably clobber one of `list' and `history', but what I chose to
be the less "necessary" and take out of the "small" Lynx, someone
else might think was indispensable.  Another example would be the
chartrans tables, but I'd probably confer with the list to get a
compromise on a small set.

Would appreciate feedback on this idea.  If it seems to be a "go
ahead", we'd be looking at mid to late December for the first attempt.

__Henry