lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev LYNX: "\"-html-screen truncates


From: Jacob Poon
Subject: Re: lynx-dev LYNX: "\"-html-screen truncates
Date: Fri, 31 Jul 1998 23:39:21 -0400

On Fri, 31 Jul 1998, Doug Kaufman wrote:

> On Fri, 31 Jul 1998 address@hidden wrote:
> 
> >>Maybe I am missing the point. Right now, you can see the source
> >>wrapped. It is there, just off the screen with no way to scroll right.
> >>Just "print" to less. You can then see the full source, either wrapped
> >
> > But why the heck should you have to do this?
> > 
> > Isn't HTML source "white space ignoring"? So if you simply wrap the
> > lines (not even at word breaks necessarily), you're not giving an
> > *incorrect* view in any way.
> 
> The point is that lynx is not a text file viewer. Html source is
> frequently wider than the screen, but lynx has no code to scroll left
> or right. Less and most are designed as text file readers which have
> this ability built in. Lynx already uses external programs for many
> functions (e.g. telnet, sendmail). If we try to put in code for this,
> it has to be maintained. I believe that most users would want "\"
> to give an exact picture of what the source actually is; otherwise
> problems might be obscured by your proposed rendering of the source
> into a file that fits on the screen.

First, if Lynx is not a 'text file viewer', then I shouldn't be able to
choose to view a file with text/plain MIME format in Lynx at all (in this
case I have to d)ownload).  However, I can still see text files on screen
with Lynx without saving it into a local file first, nor do I need an
external viewer. Therefore Lynx is just as much as a 'text file viewer' as
[insert text file viewer here] does, except that Lynx is also capable of
rendering HTML, getting FTP connections, sending mail, etc.

Second, if SOURCE command is supposed to give the 'exact picture' of the
source actually is, then why when I use the p)rint command to save the
'source' representation of current URI, then compare it to the original,
the long lines are still _truncated_ by Lynx's p)rint command?  If user
can see the 'exact formatting' of the source by using SOURCE command, then
why on a 80-column terminal window, Lynx only shows long source lines up
to the 79th column, but not the 80th column?  To me, it is a misleading
statement to begin with.  After all, if I expected to see the 'exact
picture' of the source, whenever I want to print the URI I am viewing to a
local file with SOURCE command active, of course I want it to have
identical contents (in binary term) as I download it, without Lynx hacking
up long lines at local output. 

However, this is not what Lynx's SOURCE command provides.  What Lynx
provides is only an _approximation_ of source URI formatting, with
untranslatable/unprintable codes get filtered and long line truncated,
even when I try to print it locally to a file. Therefore lack of text
wrapping in source mode can hardly be justified for on-screen viewing
since even the 'source' view of an URI is always formatted by Lynx anyway. 

What about obscured problems?  With long lines get frequently chopped off
instead of displayed by Lynx, how much more obscure can you get than that? 

As for maintaining text wrapping code when viewing source, I don't think
it requires frequent maintenance since text wrapping is part of Lynx's
HTML rendering code.  You just have to parse the URI differently (and
much more simply).

reply via email to

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