Re: lynx-dev (Forward) modify to draw table

[Heather Stern]

Philip Webb wrote:
> 990705 Bernard Liang wrote:
Bernard Liang> > I have been assigned to extend lynx to be able to draw table.
Philip Webb> that's quite a big job: if this is a student assignment, get 
             it changed.

The whole idea of it has been hotly argues a few times - definitely visit
the lynx-dev archives and search on it.

Though I'm sure someone would be willing to offer "to do" items that have 
been requested and might be easier.

Documenting the programming logic such that it's useful to other new
programmers probably would be a worthy student project - depending on
how much time was assigned.

> > Q2) Do you have any advice on how to study the 2000 pages of code?
> 
> patience? fortitude? prayer?  we all find it intimidating (smile).
> if you have a specific point of inquiry, you may get a bit of help,
> but everyone is a volunteer & the rule tends to be `do it yourself'.

Debian has a mailing list dedicated to newbie programmers.  While it
would surely be aimed toward Debian in scope, the abilities that make 
one a good programmer would probably be enhanced by following that list's
archives.

As for how I'd do it (I speak from experience, but not on lynx' code
specifically) - there's the "desk check" approach, and there's the
"one at a time" approach.

"desk check" - play computer with it.  Have a slab of paper handy to
allocate variables and other resources with.

"one at a time" - what it says, try to understand functions individually,
play with them a little, see if you can find their neighbors.  Great
if you can't stand starting at main()

> > Q3) Please can you give me some hint on the user-displaying mechanism?
> 
> do you mean rendering the HTML (etc) source into the screen display?
> that's a very complex business: again focus on some detail.

Depending on your compilation, slang, some flavor of curses, or... uh,
I dunno what VMS uses.  

We have abstractions to defend the parser from the straight display 
mechanism - I hope - if you end up considering changing that, go back
to "too big to be a student project".

Though I don't know if you're a student, we're just guessing from the 
.edu. buried in your email address.  

> > Q4) Please can you give me some advice on how to draw tables?
> > I am worried there actually isn't a parser
> > that can read something like <TD COLSPAN=2>

I get the feeling that Lynx just watches caode as it flows by, pulling 
tags and adding placement logic.  So it would be another item to listen
to - which wouldn't mean "table" any more than it does now, until you
train it.

> Lynx doesn't attempt to parse tables as such,
> merely to list their contents on the screen.
> there has been much debate about how it might be done,
> but so far no-one has offered patches to make it work.
> if you can do so, your efforts will be greatly appreciated.
> 
> > The specification was to be able to draw out tables with boundaries
> > using only ascii alphabets and special characters,
> > but it seems to me that it is difficult enough already without boundaries!
> 
> quite correct!

Yeah - right now we're dodging the whole crazy set of heuristics that W3C
suggests for table calculation, but we listen enough to defend against
folk who no longer bother to properly use P containers (only on the row
boundary, according to my brief abusability test).

I guess that your requested spec argues against gathering it up like a 
USEMAP and replacing big blocks with [TABLE: whatever the caption tag says] 
hotspots, creating a popup area and showing each cell as you move over it,
or turning it into a more unusual OL/UL type list with bullets like
"Row 1 Col 3:". 

Commentary:  I don't like [TABLE:foo], unless maybe the current non-table 
style is still used for "BORDER=0" type tables.  The OL/UL/TABLE list style
would probably at least read-out-loud okay.  I have no idea if a cell popup
would be more annoying than good - but it might be reusable for other kinds 
of extra support, like pseudo-frames.

I'd probably experiment with treating TABLE as HR, \TABLE like HR, 
and \TR like less wide HR.  We already draw ascii lines for those.

Best of luck, welcome to the crew.  But I agree, adding a major feature
here isn't a homework assignment type item.  Redesigning lynx
(i.e. supporting all current features, but changing how its inner workings
are laid out) might be a PhD thesis type item, since we're involved in so 
many platforms.  Make sure your boss or whoever it was assigned you this,
is not expecting too much for the time and resources you've got for it.

* Heather Stern * address@hidden * Starshine Technical Services *