Re: lynx-dev TRST : the next step

[Philip Webb]

991119 Klaus Weider replied to Philip Webb:
PW> i already said i have no interest in practising awk/sed.
PW> i estimate that it would take me a couple of months' serious study
PW> to revive my lapsed C, learn how other people program in it
PW> & get a thoro' enough knowledge of Lynx innards
PW> to start to create useful feature patches. 
> you are not 'interested' and insist the only acceptable solution has
> to be C code in lynx.  Maybe that prejudice is all that will prevent you
> seeing those ocaa tables rendered nicely in a reasonable time frame.

let's avoid dwelling on words like `interested' & `prejudice',
which only distract from the real discussion (that's `dwelling' on ... ).

i have no reason to practise awk/sed as such,
but that doesn't mean i will never try to use them
to solve my problem with tables like those in the OCAA report;
it doesn't even mean you won't succeed in provoking me to show
that any table whose HTML is reasonably valid can be rendered properly
using simply the utilities  sed awk tail  described in Kernighan+Pike,
which is what i have used in the past (and the recent table example).
 
> External scripts make it much easier to explore approaches
> which, after proven successful, might be put into the lynx code.

if that means you want me to do half the work, no problem;
of course, i would get half the credit too ... (smile)
 
PW> what's needed is C programming in Lynx, so see my other message today.
> You offer arguments why one-parse-rendering should not be a show-stopper.
> Maybe those are important questions, but they are secondary.
> Your message doesn't come close to proposing an way
> for actually doing the hard parts: the actual table formatting
> and, much more difficult, doing it in the context
> of Lynx's given data structures.

i haven't read your reply there yet,
but you're showing a serious lack of imagination: under my scheme there,
Lynx would not need to go thro' any of its existing inner processes
& could use quite simple data structures designed to fit tables.
to emphasise again, the aim is to handle ordinarily well-composed tables
like those in the OCAA report, at the user's discretion.
 
> *i* am looking at Tom Zerucha's script & proxy stuff now
> (for the first time seriously).  It is already convenient to use,
> in my opinion (and in my situation).  Improving this approach looks
> more promising than waiting for someone to put in the months (or years?)
> of C coding, which we've been doing for years.

certainly, to me TZ' code looks very much like C ...
 
> you may want to review the thread
> <http://www.flora.org/lynx-dev/html/month0699/threads.html#00328>
 
all it seems to say is to try using scripts etc: nothing new.

can we keep the discussion under the other thread from here on, please?

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto