lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Re: Setting up a fund for specific development?


From: Andrew Kuchling
Subject: Re: LYNX-DEV Re: Setting up a fund for specific development?
Date: Tue, 6 Jan 1998 11:52:49 -0500 (EST)

Greg Stark <address@hidden> wrote:
>Larry W. Virden, wrote:
>> If the lynx community is unable to come up with developers who want
>> to work on it for free, then it probably has reached the end of it's
>> life cycle from a community point of view.
>                If people need a feature in
>software they use they should contract someone to add the feature. Once
>written it should be available to all -- the sale was of the service of
>writing the feature and the software itself is not property.

        That's certainly feasible, but it's not the major problem.
Certainly one could pile together some money and pay someone to
implement tables or whatever for Lynx.  But why aren't people working
on Lynx on their own?  Few people are paid to work on, say, Linux or
Emacs, yet they do so.  

        As I see it, the central problem is lack of interest from
technically capable people in improving Lynx.  Lynx is used by many
Unix hackers because of its simplicity and speed, but few are
interested in enhancing the program.  Is that because Lynx is already
good enough for them, and missing things like table support aren't
that critical?  Is it because of lack of awareness?  Is it because web
browsers, like word processors, aren't exciting projects like kernels?
(Maybe; other freeware browser projects such as Mnemonic also attract
little interest.)

>PS: I'm seriously considering working on table support for Lynx. But I haven't
>looked at the Lynx source. Is there anything about the Lynx design that makes
>it hard or are people just being intimidated by the complexity of html tables?
>(The latter doesn't faze me. i worked on Emacs-W3's table support. The former
>could send me running back to lisp:)

        The HTML parser presents problems because its use of global
variables prevents recursive parsing, which is required for tables,
and because it's a one-pass parser.  As an initial step, you'd have to
push all these globals into a C struct, and then modify a lot of
functions to receive such a struct as a parameter.  (Or, do some hack
which saves and restores all the relevant globals from a stack.)
Then, tables really require several passes, to gauge the size of the
cells, render them offscreen somehow, and then size the table
accordingly, so Lynx's HTML parsing will really need a serious
overhaul.  That's a lot of work, which no one has done, and no one
seems really willing to do.

        See the thread "Centering <PRE> text" at
<http://www.flora.org/lynx-dev/html/month0597/threads.html>,
particularly the messages by Klaus Weide and Alan Cox, or the thread
"table toggle" in 04/97.  I seem to recall a post where Foteos mapped
all this out in much greater detail, but couldn't track it down in the
archives.
        
        I've thought similar things about JavaScript support; it's not
so hard to write a parser for the language, but implementing all the
different properties of fields and documents looked extremely painful,
and making things change when JS code poked them, seem to need code
added all over the place in a messy way.  Perhaps only a complete
rewrite would fix things.  (Or maybe Emacs-w3 is more easily
extended?)

        
        Andrew Kuchling
        address@hidden
        http://starship.skyport.net/crew/amk/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]