lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Why does Lynx do it? (fwd)


From: Vlad Harchev
Subject: Re: lynx-dev Why does Lynx do it? (fwd)
Date: Mon, 7 Jun 1999 14:04:43 +0500 (SAMST)

On Sun, 13 Jun 1999, Klaus Weide wrote:

> On Sun, 13 Jun 1999 address@hidden wrote:
> > > 
> > > > I have noticed a bug in Lynx (v.2.8rel.2).  When I change the disply
> > > > character set to DOS PC80xx and view my bookmarks page with the
> > > > space bar, Lynx goes berserk.  It looks up an address, dumps me into
> > > > the Options page and then often puts some characters in the "Display
> > > > Variable" area.  I had this problem with older versions of Lynx, but
> > > > is 2.8 really that old?  Is there something I need to configure to
> > > > have it work normally, enabling me to view the higher order ASCII
> > > > characters?
> > 
> > I am using Lynx from a Unix shell account via VT-100 terminal
> > emulation connection (no PPP).  I use Comit communication software on
> > my DOS (v.6.22) IBM compatible (386).  I have tried a more recent
> > version of Lynx (2.8.1, rel.2, 1998) and have had this wild loop
> > problem whenever I attempt to access a variety of sites (e.g.,
> > http://members.eb.com).  It happens only when I switch "Display
> > Character Set" in Options to "IBM US CODEPAGE, CP 437".  It happened
> > in older versions even when I left the character set at ISO Latin 1. 
> > It is not a very serious problem, but perhaps it will cause problems
> > when I least expect it.
> 
> My guess at what's happening:
> 
> I am not familiar with the Comit software.  But apparently it
> interprets some characters with byte values in the range 128-159
> as control characters.  One (or more) of those characters causes
> the terminal emulation to automatically send a response, which
> Lynx takes as key input.
> 
> If this is the case, the problem is with your comm setup, not
> with Lynx.  If ISO Latin 1 (or similar) is selected, Lynx knows
> that bytes 128-159 cannot be valid characters, so it tries to never send
> them.  (As you have observed, older versions may not have always done
> this.)  But for other display character sets like cp437, cp860, ...,
> bytes 128-159 are valid characters.  Selecting those character sets
> implies that their 8-bit characters can be safely transmitted.
> 
> There are various files distributed in the test/ subdirectory
> that could help you nail the problem down.
> 
> I suggest you either
> (1) configure Comit to act differently, if that is possible; or
> (2) switch to some other comm software that doesn't have this 
>     problem.  I guess most other comm programs don't have the
>     problem, otherwise we'd hear more about it.
>     One possibility is to let the comm software do the translation to
>     the PC code page for you (you would then set display character set
>     to Latin 1 in Lynx).  This should work very well with Kermit.
> (3) You could set display character set to Latin 1, and install an
>     iso-8859-1 code page on your PC.  Some hints for this can be
>     found in
> <http://ppewww.ph.gla.ac.uk/%7Eflavell/iso8859/iso8859-pointers.html#cp819>.
> (4) You could set display character set to 7 bit approximations,
>     if that is satisfactory for you.
> 
> (1) or (2) should be preferred, since I expect you have the same
> kind of problems also with other programs.  For example if you just
> 'cat' a file with some of those characters.

 Wise ideas. May be this question (and answer) should be added to FAQ?
 
> 
>    Klaus
> 

 Best regards,
  -Vlad


reply via email to

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