[Top][All Lists]

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

Re: lynx-dev TRST : the next step

From: Klaus Weide
Subject: Re: lynx-dev TRST : the next step
Date: Fri, 19 Nov 1999 02:40:12 -0600 (CST)

On Wed, 17 Nov 1999, Philip Webb wrote:

> 991117 Klaus Weide wrote: 
> > Try .
> > Take a closer took at Tom Zerucha's stuff.
> > try his proxy in <>.
> he has two gawk scripts, which use functions;
> we only have awk, which doesn't know about functions.
> with functions, you're more/less writing C programs anyway.
> > you could probably easily write something that preprocesses
> > 
> >  <TR><TD>Blah<br>more blah</TD><TD>Other blah<br>more other blah</TD></TR>
> > 
> > into
> > 
> >  <TR><TD>Blah             </TD><TD>Other blah                   </TD></TR>
> >  <TR><TD>        more blah</TD><TD>              more other blah</TD></TR>
> > 
> > (spaces left only to show correspondence better).  Generalize as necessary.
> i already said i have no interest in practising awk/sed.

But you could, and without all of the following penalties:
(quoted from a different message)
> i estimate that it would take me a couple of months' serious study
> to revive my lapsed C, learn how other people program in it
> & get a thoro' enough knowledge of Lynx innards
> to start to create useful feature patches. 

But you are not 'interested' and insist that 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.

> i also say Lynx should render ordinary tables properly & thought you agreed.

It is hard to disagree with such a statement if it is taken as a general
wishful 'should'.  But I certainly didn't say that all efforts at finding
solutions with external scripts should be abandoned.

On the contrary.  External scripts make it much easier to explore
approaches which, after proven successful, might be put into the lynx code.

> what's needed is C programming in Lynx, so see my other message today.

You are addressing some user interface questions there, and offer some
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.  Concentrating on
those secondary questions would be the cart before the horse, IMO.

(some more comment will follow in separate message)

Anyway, *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.

If the script solutions look overly complicated and inconvenient and
not usable for most "normal" users - maybe it's because nobody has
written some easy how-to-use intro, and packaged it in a convenient
way?  (and perhaps worked on perfecting the approach)?  And maybe *that*
is because those who would do such things are just 'not interested'? :)

As for how all this relates to TR*S*T (since that's still in the subject
line) - TRST is about as far as it can go *without* raising a bunch of
new problems (like the ones you address in that other message).  Maybe
it can go a bit farther, but not too far.  When it *does* handle a table,
it does it well enough to not make it necessary to have new user interface
elements (decision to explicitly turn on etc.).  That's a definite
advantage IMO.   (Yes, I realize Kim(?) wants to add a toggle, but so far
it hasn't proven *necessary* to have one.)

Btw. you may want to review the thread
in this context.


reply via email to

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