Re: lynx-dev Danish translation of lynx

[robert bonomi]

> From: address@hidden
> Message-Id: <address@hidden>
> Subject: Re: lynx-dev Danish translation of lynx
> To: address@hidden
> Date: Tue, 9 May 2000 00:15:32 -0600 (MDT)
> 
> In a recent note, robert bonomi said:
> 
> > Date: Tue, 9 May 00 00:48:08 CDT
> > 
> > There were terminals that did 'auto-line-wrap' when you wrote in
> 
> Presumably termcap/terminfo/curses are able to keep track of this.  At
> worst you can explicitly address the cursor to the beginning of each line.

False to fact, unfortunately.  Some of those @#$%^& machines, when they
'auto-wrapped', even in the _middle_ of the display, *cleared* the next
line from edge to edge, _as_ they put the cursor on that line.

very much like the way the unix 'talk' program works.

> > the last character on the line.  *AND*, if it was the bottom row of
> > the screen, it would *SCROLL* the screen -- with catastrophie results
> > as far as knowing "what's whare" on the screen.
> > 
> This only applies to the last line.  Use the last line for status
> messages, and restrict it to width-1, or if necessary, width-2.

In the worst-case scenario (auto-wrap, *with* 'auto clear next line')
you can't touch the last column on _any_ line.  you're thus restricted
to 79, everywhere.

> IBM 327x.  But these don't support curses, so they're irrelevant to
> lynx.

Thy don't support ASCII, character-by-character transfer, or a bunch
of other things lynx needs.  Hell, you've got a completely separate 
'send' key.  And it causes the _only_ the 'input parts' of the screen
to get sent back to the host.  WITHOUT any indication of 'where' the
'cursor' is, even.  Which would make it -very- difficult to figure out
which link they wanted to go to.

Oh, yeah,  the IBM 3727x specficiation is an early 1970's design, at
the latest -- minor modifications, at the most, to a design that dates
from roughly 1966.

> If "vi" can figure it out and use the entire screen width, why can't lynx?

I'm not knowledgable about _lynx_ internals, but, 'traditional' vi (i.e.,
the 'real thing' as shipped with the AT&T/UCBerkeley products, not one of
the 're-implementations', like 'nvi', or'vim') does *not* use any attribute
stuff _in_the_text_ itself.  It also _does_reduce_ the 'usable' screen width
on screens that have the  autowrap and/or autowrap w/ clear issue.  People
who only use 'sane' devices havn't experienced the other behavior.  For those
who _have_ had to program for the 'other' types, a name like 'beehive', or
a DTC 382, early Hazeltines (e.g. the H1000) should bring sufficient shudders.
( The comments in an un-bowlderized termcap file were _quite_ entertaining
reading, if you ran to that kind of humor.  Like the comments about one
device where one of the cursor keys generated CTL-S.. )

Now, lynx _could_ do the same thing with the the 'page content' stuff it
displays.  HOWEVER, the discussion was with regard to porting to other
language environments, and the messages and such that Lynx *itself* 
generates.  For _that_, you *have* to stay within the bounds of the 'least
common denominator', so that things -don't- break, when run on one of
those 'less than sane' pieces of equipment.

> >From the mainframe world, I have lots of potential "file://" URLs with
> 80-column wide data, even if it's only because they're blank-padded to
> 80 columns or have line numbers on the right..  It's a genuine irritation
> to see these double-spaced on a default 24x80 xterm.
> 

Now, -that- is a different issue.  I'll readily agree that 'trailing white-
space _should_ be 'fair game' for elimination by optimization.

"punch-card" line numbers deserve whatever happens to 'em.  <grin>


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden