lynx-dev
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: Vlad's suggestions

From: Vlad Harchev
Subject: Re: lynx-dev Re: Vlad's suggestions
Date: Sun, 7 Mar 1999 03:53:03 +0400 (SAMT) 
On Sun, 7 Mar 1999, David Woolley wrote:

> > > > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> > > > <HTML><HEAD><TITLE>e</TITLE></HEAD>
> > > > <BODY LANG="EN">
> > > >  <A NAME="tex2html11" HREF="node1.html">
> > > > <UL> 
> 
> Invalid HTML (unclosed anchor); all bets are off.

  Sorry about that. I was in hurry when cutting and reformatting the html
  code I decided to present here. Nevertheless, the file is rendered ( and
  handled ) in the same way as correct file (without that unclosed <a> ) 
  will be. So you can observe buggy rendering even on that illegal code.
   
> > > > <LI> <A NAME="tex2html36" HREF="node23.html">IPC Identifiers</A>
> 
> > > <b> & <i> are recognised if you use  ^v  to get `sortasgml' a/a `tagsoup'.
> 
> I'm not sure which way you are going here, but <b> and <i> are never
> valid in <pre>.

  It seems that most browsers (at least NS, kfm and lynx ) allow them.      

> >   used to pack some words (eg Microsoft to M$). It seems to me that it
> >   will be possible to implement table renderer in Perl or Python that will
> >   render the table to the <PRE> block. Even simple javascript constructs
> 
> Proper table rendering could easily exceed the maximum pipe size, requiring
> non-trivial support within Lynx.  Also, you have thrown away all the 
> information that Lynx has collected on the document.  If there is a sensible
> way of rendering tables in 80 column text only, it should probably be an
> internal option.
> >   can be parsed and interpreted (like document.write). Complex character
> 
> Why do people think that document.write is simple?  Firstly it is generally
> always within a conditional, even if that conditional is just the implied
> one that the browser fully supports Javascript, but also because it
> can generate arbitrary HTML, including further instances of document.write.
> HTML which fails to parse when you delete script elements is invalid HTML.
> 
> In the general case, you need a full HTML parser to know whether the
> <script> is CDATA, normal content or comment.   document.write could be
> in a subroutine and its paramter could be calculated.
> 
> >   set translations will also be allowed by this approach.
> 
> Can you give a real life example where this would be a better solution
> than enhancing Lynx's character set support to cope.
  
  Anyway, adding ability to pipe the data being received will make lynx
  more flexible. The regexp searches can be implemented quickly and
  roughly using sed: write script that accepts RE to search for as
  commandline argument (or better multiplie arguments - for several
  REs to search in one query). It should  emit the rule that
  will remove all comments, and then add a rule composed of the RE to search
  for (possibly substituting spaces alone with " \t\n")  and substitute
  the found phrase with itself surrounded with some characters (say pair
  of stars). Then user can search for that pair of stars using facilities
  lynx provides. Of course, the document should be completely reloaded
  when another RE query is requested but proxies can compensate this. May
  be caching of original data should be done by lynx - in this case no
  additional penalties will be in effect. Of course this is rough enough,
  but it's better then nothing - and RE searches got in such cheap way
  without extending lynx code in some complex way - I think it's very
  nice.
  
 
> >   It's convenient for GUIs and UIs to interpret ESC (or double ESC) as 
> >   closing current element of dialog or dialog itself. May be it will be 
> >   useful for novice users.
> 
> This is a very long standing abuse of ESC, even vi does it, but vi was
> originally written for use without keyboard generated escape sequences.
> Correctly used, ESC is the start of input in a special mode, not the
> end of input or a cancel.  It is misused because escape sounds like 
> getting out of a difficult situation.  This is not a problem on GUIs
> because they see key up and down events, not the escape sequences that
> are sent from a serial terminal, so ESC is just another key on the 
> keyboard, with a rather funny name.  With a serial terminal the only way of
> distinguishing between escape and the start of an escape sequence is to
> wait.  On modem or telnet connections, a transmission delay could 
> happen between ESC and the rest of the sequence.
> 
> Double ESC is a way of making ESC unambiguous but, in my view, would 
> confuse the average Windows user at least as much as using an alternative
> key.
> 
> The way to handle this properly is to map ESC only in the Win32 builds.
> I haven't checked, but it may well be possible to do this from the
> configuration file already.  The most likely problem is that escape
> sequence parsing has already been done.
> 
  May be simply prompt should contain something like (leftarrow to
  cancel?)

 Best regards,
 -Vlad
reply via email to
[Prev in Thread] Current Thread [Next in Thread]