lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev 2.8.2dev.19 patch 1 - small ebcdic fix


From: Klaus Weide
Subject: Re: lynx-dev 2.8.2dev.19 patch 1 - small ebcdic fix
Date: Mon, 8 Mar 1999 17:16:10 -0600 (CST)

On Mon, 8 Mar 1999 address@hidden wrote:
> In a recent note, Klaus Weide said:
> 
> > Btw, PG if you are reading - did you see my note
> >    <http://www.flora.org/lynx-dev/html/month0299/msg00314.html>
> > referring to dev.15 -> dev.16 changes from
> >    <http://www.flora.org/lynx-dev/html/month0299/msg00186.html>?
> > 
> Thanks for pointing this out.  None of our S/390s are running sendmail,
> so I can't fully test this.  But I made the changes that appeared necessary,
> aliased "cat" as "sendmail", and inspected the output.  Patch attached.

You don't need to go to the sendmail level to check *some* of this -
Lynx's mail composition dialog should already show whether it has picked
up the subject.

For the message-id stuff - make a local copy of any of the lynx-dev
archive messages, then mess around with the embedded
<!--X-Message-Id: ... -> string - but you probably have already
done this.

You know where the letters and numbers are in the EBCDIC table, so
it should be much easier for you than for me to make a test case where
(unsigned char)*p >= 127 is different from !LYIsASCII(*p) for one of
the printable characters.  :)

> > Seems to me EBCDIC needs this small fix - no way to test it though.
> > * Fix of HTUnEscapeSome for non-ASCII.
> > 
> Do you mean that lacking an EBCDIC platform, you are unable to
> test it, or that there's a fundamental obstacle to testing?  :-)

The former.

> If the former, can you point me at a URL on which it should make a
> difference?  I tried it on one of the entities tests distributed with
> Lynx, and could see no difference before-and-after patch.

The HTUnEscapeSome shouldn't have anything to do with the entity stuff.
It is used in handling local file URLs, mostly in connection with DIRED,
for unescaping %2F to '/' (while leaving other %-escaped character for
later).  I guess a test case would involve entering file URLs with
some '/' need- and senselessly replaces by %2F, but those %2F should
always be unescaped eventually anyway (if not by HTUnEscapeSome then
by a later HTUnEscape), and I don't have a definitive test now.
If I come across something I'll let you know...

   Klaus

reply via email to

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