Re: LYNX-DEV hodge-podge of topics (was Lynx updates)

[Foteos Macrides]

Klaus Weide <address@hidden> wrote:
>On Mon, 11 Nov 1996, Foteos Macrides wrote:
>
>>      I am still disappointed that the unicode handling you volunteered,
>> and were working on, was left as a hodge-podge of mods to an old FM code
>> set instead of a clean, up to date, distributable supplement to the v2.6
>> release, when I announced, in early Sept., that I wasn't starting another
>> FM code set, and that people should bring their patches and supplements
>> up to date with the v2.6 release.
>
>Believe me, I am not happy about the state of that.  But if you were 
>expecting from me a "clean, up to date, distributable supplement", done
>by me alone, then you were expecting to much.

        Nobody could do that, at present.  But why not bring what you
*have* done "up to date" with the v2.6 release (plus Composite, at this
point, I guess), as a complete file set, that those who know at least
something about it can work on further?


>What I was trying to offer - maybe I didn't make it clear enough then -
>was to provide some functions (or methods in another form) to do the
>translations between different character sets.  I did not aspire to
>provide a full solution on my own.  There are some questions about
>how such translations should be used, and how they would fit into the 
>Lynx code, that I didn't want to answer alone.  I started bringing
>some of them up on the list (like: is the SGML.c function the best
>place to do this, should this be done in a separate stream object),
>but came away with the impression that either you were not interested
>in that level of discussion, or the list just plain doesn't work for
>that kind of questions.  So I stopped trying to figure out these basic 
>questions in a collaborative manner on the list, and instead just
>continued hacking my own code version.
>
>I would have appreciated some indications whether I was on the right 
>track with my ideas, what I got were some expressions of general
>interest; but nothing enough to go on, to make decisions like "where
>should these functions be called" for integration into the distributable
>Lynx code in a clean way.  If you hoped I would figure it all out
>myself, well it didn't work out that way..  that's why my personal
>hacks remained just that.  I don't want to become another contributor
>of additions that seem great just now because they add some needed
>function, but become a burden for further development later because
>they don't really fit in with the overall architecture.
>
>Let me restate my offer:  I provide a set of functions (or other means)
>to translate between charsets (including ways to load and store those
>translations).  YOU tell me what interface you want, and put calls to
>those functions in all the necessary places where translations have
>to be done; or YOU are willing to tell me, slowly enough, where exactly
>I have to look to do this myself (which means I have to know where a
>byte is supposed to express _which_ charset); or WE enter into a 
>discussion to figure these things out together. 
>
>Now, the capitalized "YOU" in the last paragraph doesn't have to be
>"Foteos Macrides, as project leader".  It could be FM, as an expert
>on the Lynx code in the best position to know and discuss.  It could
>also be "you Lynx developers and hackers".  It's up to YOU to answer. :)

        The "YOU" can't continue being just "Foteos Macrides" indefinitely,
If you make available an "up to date" file set that actually works on
your system, I'll certainly try it on mine too.  If it's miles from
anything that could be make to work on VMS, I'll probably pass on getting
actively involved, but you had indicated that it would be "portable" code,
not Unix-specific.


>Those translation functions are basically already there - my hodge-podge 
>version is proof that they can work.  The current charset handling in
>Lynx is sufficiently complex, scattered over different files, full of
>exceptions, and confusing to me that, sorry, I cannot do it on my own
>(within a reasonable amount of effort and time).

        You shouldn't try to do it all "on your own".  But something,
somehow, has to spark a true "Lynx User Community" *development* effort.
Maybe this will provide that spark.  Maybe it won't.  Give it a shot.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;