[Top][All Lists]

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

Re: lynx-dev Posted message has no text error message

From: Vlad Harchev
Subject: Re: lynx-dev Posted message has no text error message
Date: Sat, 5 Feb 2000 16:35:34 +0400 (SAMT)

On Sat, 5 Feb 2000, Henry Nelson wrote:

> >  I that if somebody wants to send escape sequences, this person will use 
> > other
> > tools (probably perl) rather than invoking external editor from lynx 
> > manually
> > and typing something wrong there. Also, good newsreader won't send raw 
> > escape
> It's not that they "want," it's that they may carelessly or inadvertently
> send escape or control sequences; at times with disastrous effects on the
> receiving end.  (I know that if I receive certain one-byte kana in news,
> sometimes it locks up my terminal so that the only way out is to shut down
> the terminal emulation program.)
> >  So, I think there is nothing of real concern here - it's better to fix the
> > bug in that way it's done, rather than doing what idealized thinking 
> > suggests.
> Again, I have to disagree with you vehemently.  You have been on the list
> long enough now to know that Lynx has a rather foul name when it comes to
> it's news module.  There are some news buffs who have severely criticized

  Yes, it's a hack.

> Lynx for it's poor news handling and recommend that the news portion be
> stripped from Lynx.  We leave it in because it's convenient and already
> there; anyway, it's not as bad as some would make it out.
  I think we are doing right thing by not removing it. 

> Making it even more less-than-ideal won't help matters, and in particular
> could harm Lynx's reputation.  Just because Lynx isn't a news agent per se
> doesn't mean that anything goes.  It should strive to be as compliant as
> possible if it is going to stay.

  Of course it should - I'm not against perfectness, but who will do it?

> > receiving side) - this means that 'isgraph' test is useless. The only
> > check to be applied by lynx should be to insure that message sent is
> > non-empty (and it uses "message has no content" message currently!), rather
> > than trying to filter out escape sequences, IMO.
> This exactly is where I admit I do not have enough knowledge to argue.
> >From my layman's perspective, however, having a news agent that blindly
> will allow the user to send escape sequences that could completely confuse
> the receiver's terminal seems wrong.  Although I sent a message with only
> euc-jp to see if the phenomenon was real, I also know that that is not the
> correct way to post messages in Japanese.  Since Lynx does not convert to
> safe encoding (way beyond Lynx's capabilities, and doubtful that such
> capability should be included), it is up to the user to manually convert.
> Since Lynx cannot do the conversion, I think it should do the next best
> thing, i.e., it _should_ indicate to the user that the "message has no" *
> ascii/terminal safe * "content."  Granted it would be much friendlier if
> Lynx were to keep the message around so that someone who forgot to do the
> conversion of multi-byte characters wouldn't have to retype the whole thing
> again.  (But again, Lynx isn't a real news agent.)
> To use my personal example, if I convert the content to ISO-2022-JP, I
> have no problem whatsoever in posting with Lynx.  So actually, Lynx is
> doing everyone a favor by forcing me to use proper encoding rather than
> euc-jp or shift-jis which someone might not be able to read, or worse,
> force someone's terminal to freeze up.

  For japanese, there is encoding that is 8bit clean (I guess). There is no
such encoding for cyrillic and probably some other language. So, you can
consider the bug present in lynx as protection from sending japanese text in 
wrong encoding, while russians and others using cyrillic will still consider 
it as bug that prevent using external editor for sending messages in cyrillic.
  Original implementation used wrong (IMO) logic for determination whether the
message is empty - ie contains only blanks. I fixed (IMO) that logic. I didn't
extend lynx capability of rejecting messages in wrong encoding (and won't do
- lynx shouldn't reject such messages unconditionally).

 At least I promised myself not to extend lynx signtifically (patches larger
than 8K) until real support for tables is added by someone (may be me). I
don't want to spend time on makeup of a dead animal.

 Best regards,

reply via email to

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