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: David Woolley
Subject: Re: lynx-dev Re: Vlad's suggestions
Date: Sun, 7 Mar 1999 13:28:45 +0000 (GMT) 
> > > <!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.

> > > <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>.
     
>   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.

>   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.
reply via email to
[Prev in Thread] Current Thread [Next in Thread]