lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV Parser stuff (was: Another fotemods.zip update)


From: Al Gilman
Subject: Re: LYNX-DEV Parser stuff (was: Another fotemods.zip update)
Date: Fri, 18 Apr 1997 10:50:26 -0400 (EDT)

  From: address@hidden (Larry W. Virden, x2487)
  
  Al Gilman>
  >          I don't think that we should be too religious about "the
  > true source."
  
  Well, _I_ would have a real problem if the file I save in at least the \
  mode isn't _identical_ to what was on the server.  I use this method
  to save source code examples or data files.  Doing word wrapping on such
  things would really screw things up - making it basically impossible
  to use lynx to download files from the net.
  
It would just force you to go back and d)owload them without
peeking.  But I buy your beef.

  > So long as the word-wrapping introduced newlines only where there
  > was whitespace before, the result is equivalent HTML, no?
  
  no - because not everything lynx shows is html.
  
ALLright, IF it were HTML, AND wrapped between words, ...

What have I learned:

There are cases where wrapping can help, and where it can hurt.

There is a need for a flat-out _literal_ view as well as
download.  This is used all the time in SysOp applications -- a
significant customer group for Lynx.

It seems that the additional "reveal codes" mode Rob hypothesized
-- without necessarily preserving source file layout -- would
have a market and would reduce the demand for a wrapped
view-source presentation.

Perhaps we need to question the short-cut: "source is
text/plain."  The cases Larry and I brought forward indicated
that I want access to wrapping for HTML source and he wants
protection from wrapping for text/plain.

In view-source, the object being viewed is still text/html even
if you chose to disable parse/render for a particular look at a
particular object of this type.

What if the response to the e)dit keystroke for an http: -
accessed object were to re-fetch and load into your selected
editor (which will do things like wrapping for you) with a brief
warning that what you are doing is creating an edited local copy
(and query to confirm local filename, as in download)?

I think that extending e)dit is more generally useful than
reveal-codes and would meet my needs.  That is, if view-source
yielded an unusable view because of long lines, and I wanted
wrapping, I would back out and e)dit the page whereupon I knew
that I had bought responsibility for changing it.

--
Al Gilman
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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