Re: LYNX-DEV Re: todo-list question

[Nelson Henry Eric]

> have posted about the development code.  The (1) change in caching logic
> associated with the INTERNAL_LINK stuff (not undone by the compilation
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Okay, understood.  We've been waiting for your reply, and I saw no
reason to pry it out of you.  Is it that switching between the two forms
of logic cannot be done with a compilation symbol, or that the compilation
symbol simply was not implemented correctly?  If the latter, could you
give us a hint as to how it could be done right?  Just as many of us like
having two methods of parsing available (more below), being able to choose
between two ways of caching links is a luxury some of us would like to have.

> symbol), the (2) change in structured object interactions associated with
> the preparsed stuff (added as a debugging tool useful only to Klaus, if

Yes, I had forgotten.  Thanks for reminding me.  The references, BTW, are
under the thread "Re: LYNX-DEV fotemods chartrans & SSL"; two good ones are:
        http://www.flora.org/lynx-dev/html/month1097/msg00498.html
        http://www.flora.org/lynx-dev/html/month1097/msg00577.html
Members of lynx-dev interested in learning about the internals of Lynx
might want to bookmark these.

> anyone), and the (3) excessively complex and unmaintainable aspects of
> its chartrans implementation, still preclude my using the development

I am aware of that, and I think most of those seriously using the
develpment code are cognizant of the problems there.

> but please, yourself, stop misrepresenting what I have said.

I may have misrepresented your "vibs", but I don't see how I could have mis-
represented "what you said" because you haven't said all that much despite
our rather blatant, at least I thought so, requests for your guidance.

>       There is also the problem that the development code's
> autoconf has been done in a way that creates problems for VMS with
> DECC (which long ago replaced VAXC as it's compiler, though support

In the long run, these problems will be ironed out.  Since VMSers shy
away from the develpment code set and are not persistent in providing
information, it's pretty hard to keep right on top of things.  Look at
the 386DOS port.  Doug, Bill, Michael and others have really put their
soul into it.  When people like that on a VMS platform get involved in
Lynx, then what you are hoping for will happen.

>       There is also the issue of the "alternate" SortaSGML parser,
> which is now the development code's default.  That initally was done
> as an "experiment" (Klaus' own description) with this comment in

I agree that the default should be your "TagSoup" because it is more
friendly to those uneducated in HTML, a group into which I fall.  Perhaps
the develpers will switch it over if there is enough opinion on this
matter.  Since it was implemented as a toggle, that should be pretty easy
to do.

**************** TAKE NOTICE FOLKS ***********************

> code goes in its actual release.  If that's done now, with those serious
> problems (IMHO) still not dealt with, you could end up doing more harm
> than good for future Lynx useage.  No release can be expected to be
> bug free, but sites which wait for a "release" to upgrade do so with
> the expectation that the new features have been adequately field
> tested and serious problems eliminated.  One can be a "loose cannon"

****************** END OF MESSAGE ***********************

I practically fell on my knees and begged you to speak your piece.  Why
do you wait for prodding?  Better late than never I guess.  (Is that
"loose cannon" jive aimed at me?  If so, them's empty words, man.  Pitiful.)

__Henry