Re: LYNX-DEV Re: chartrans stuff

[Foteos Macrides]

"T.E.Dickey" <address@hidden> wrote:
>I took a quick look: no, none of #95 is my change (I did #94, #96, both
>for configure scripting).  The reason why 95's so large is because Klaus
>was adding stuff from Fote's version.  And Fote's always tinkering with
>the tabs and formatting of the code, so his changes are 2-3 times larger
>than needed.
>
>For a quick check, you should be able to ignore blanks in Fote's changes by
>doing "diff -b" to compare the files.  (It's worse than that, because he
>also splits lines).  I'd gone through a bunch of that during the summer. 
>(You should be able to ignore the stuff under the src/chrtrans directory,
>since Klaus usually just adds details and new tables).
>
>There's only a few files with a lot of changes (according to my histogram): 
>LYCharSets.c, HTPlain.c and SGML.c (either Klaus or Fote should be
>answering this stuff -- though I don't see either of them around right
>now).

        I've inferred during the past year that TD is severely lacking in
basic reading comprehension and written communication skills, so this
message is directed to the Lynx User Community, with no expectation that
TD will get it this time, any better than he has the other times that
I've posted explanatory messages about these matters.

        I am not a "currently active Lynx developer", and have not myself
inserted even one line of new code into the "official development code set".
I dropped out from "currently active Lynx developer" status upon the
release of lynx2-6FM as v2.7 on February 15, 1997.  I continued to
modify the Lynx code that I personally use, and made those mods available in
compliance with the GNU GPL, for anyone, including the "currently active Lynx
developers", to do with as they pleased, if anything.  Klaus was including
them in the "official development code set", at that time in conjunction with
amicable and courteous discussions about my mods, and others in the
development code set, with the intent and expectation on my part that the
currently active Lynx developers would thereby become sufficiently
knowledgeable about the entirety of the Lynx code set to carry the ball by
themselves.  At the typical interval for Lynx releases, my personal code set
could be considered a subset of the development code set, and the latter had
additional "experimental" or still too buggy code for a release, so my
personal code set was released on April 4, 1997 as v2.7.1.  Soon thereafter,
we parted company over the, from my perspective, severely misguided
"INTERNAL_LINKS stuff", which persist in the development code, and preclude
my ever using that code set seriously.  The quality of communication between
myself and two of the active developers (TD & KW) also deteriorated,
progressively worsing from that point on.  The "preparsed stuff" was added to
the development code set, severely distorting the underlying logic of Lynx's
structured object interactions, further preluding my ever using that code set
seriously.  The "chartrans stuff" has continued to get more complex in the
development code set, to the point where it is just plain "unmaintainable",
IMHO, even by KW.  My repeated requests to spell out the logic of the
"chartrans stuff" and where it is going, in a manner that would be
interpretable and make it maintainable by others who now or in the future have
or will join the ranks of "active Lynx developers" repeatedly went unanswered
by KW, or received "It's a long story." non-answers. The "autoconf stuff" was
done in a manner which trashed Lynx for VMS, and that has continued despite
our discussions about it, on the grounds, in effect, that TD doesn't have
"time" to avoid it.

        Things reached the point, upon my reading Henry's "pickle parable",
that I removed my personal code set from
http://www.slcc.edu/lynx/fote/patches/  and made it available only via
our gopher server, intended solely for those who needed it in conjunction
with my lynx271ssleay.zip SSL hook replacement files, and with the
expectation that the development code as it stood at that point would be
polished up for an official release, and I would fully drop out at that
point as far as making my personal code set available via a public access
server (though the GNU GPL requires that I make its source code available,
in one way or another, to anyone who explicitly asks for it).  Also, because
in my view the "chartrans stuff" was unmaintainable, I started greatly
simplifying it in my personal code set, as well as making additional
personal mods or enhancements not expected to be included in the current
development code (as opposed to new development code, after the release,
if included in the "official" Lynx code at all).  I also massively annotated
my personal code set, and cast everything into the "Lynx programming style"
that I had adopting during the years when I did most of its development, and
would do in conjunction with working in contributed mods.  A consistent
programming style, and adequate, accurate commenting of the code, IMHO
is critically important for freeware to survive changes over time in its
active developers.  TD apparently finds such "2-3 times larger than needed"
"tinkering" bothersome, even though none of that was added by me into the
official development code.  In my view, on the other hand, his dealing,
for example, with:

/*
 *  [...]  TQ_NO must be 0 since callers of functions that
 *  return this type may treat result as a boolean flag. [...]
 */

but leaving that now invalid comment in the development code set, as TD
has done, makes the "offical" Lynx code all the more "unmaintainable" and
the Lynx User Community even more dependent on particular "gurus" for it's
debugging or further development (because it's not only complex, but just
plain misleading to anyone else who looks at the code and comments to try
to understand how it works).

        The -95 and -97 development code mods were "merges", by KW, of
my "no longer available except to those needing it for lynx271ssleay.zip"
(and then "What the heck, I'll put it back on slcc if merges are still
being done") personal mods into the development code despite that it
supposedly was being polished up for a release.  The "merges" were done
without adequate testing, in many respects incompatibly with other
development code, with CHANGES.new entries attributed to me but not
accurately reflecting what ended up in the development code, and with my
lynx271f comments included but often misleading with respect to the actual
(modified) code "merged" into the development code set.   As KW put it
himself with respect to some (and not all, yet) of the bugginess created
in the development code by those "merges":

>[...]
>Yes, this is Oops!, not intentional.  With last changes, Lynx remembers
>"too much" from the previous loading when the auto-reloading after '@'
>happens.  It is a result of taking some changes (but not all) from Fote's
>code without understanding the interaction with other changes.  Will be
>fixed.
    -- http://www.flora.org/lynx-dev/html/month1297/msg00002.html

But that, and lots of other bugginess created by those "merges", have not
been fixed, and KW appears to have embarked on HREF="disappearance#2",
before an actual release "a few days before Christmas".  ;( That would be
today, right? ):

        I have the highest respect for Wayne and Doug, and others who
have contributed to the DOS/WIN/NT ports of Lynx.  It's a shame that the
fruits of their labors are still being held hostage by the consequences of
two "hon kays" who too often have in fact been loose cannons on the Lynx
code (IMHO).  I also feel bad for the Lynx User Community about the
current situation, but I've stated more than once that wherever the
"offical development code" goes is where Lynx will be in its next
release, whenever that acutally occurs, and that it's gone places that
I don't intend to follow in the code I personally use.  Sorry.

        For what it's worth, I've done some more tweaks of the "redirect
stderr via misguided equality statements" in lynx271f.zip that might help
with linux, but in effect are just shots in the dark.  If they don't help,
the alternatives are to go back to the freopen() code I used originally,
and #ifdef it out for Unix, or blow off that file output feature completely
until someone changes the zillions of  if (TRACE) {}  clauses to check a
global flag and fprintf() to stderr : LYTraceLogFP without actual
redirection of stderr.
 
        Merry Christmas and Happy New Year!!
        
                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================