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: Klaus Weide
Subject: Re: lynx-dev Why does Lynx do it? (fwd)
Date: Sun, 13 Jun 1999 23:31:14 -0500 (CDT)

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.


   Klaus


reply via email to

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