Re: lynx-dev progress...

[Henry Nelson]

> ...mulling over how to delimit their portability & packaging.

I still think streamlining lynx.cfg, and correspondingly strengthening
LYReadCFG.c, would make conversions of lynx.cfg to any form absolutely
trivial. Even if LYReadCFG.c were doubled in size, I still think it
would in the long run be more efficient and more portable. If someone
is going to spend hours anyway, why not spend it writing c rather than
using half a dozen different interpreter languages in a bunch of scripts
that only one person really knows how they work.

Backward compatibility could be made simple by doing what was done with
the old/new Options menu, i.e., parallel source trees.

There was once talk of integrating LYReadCFG.c and the parser for
.lynxrc (LYrcFile.c?). Maybe this is a reasonable time to work on that
if it is indeed the "right" way to go.

A loaded up Lynx is not necessarily a better Lynx. To me, Lynx is
beginning to look like an inverted pyramid. Hack work that needs to be
done is at the core of Lynx, not peripheral lace and frill. All the
integrating developer should have to do is hand a _work in progress_
back with directions on what form it would be acceptable in.

__Henry