Re: lynx-dev Vlad's suggestions

[Kim DeVaughn]

On Sun, Mar 07, 1999, Vlad Harchev (address@hidden) said:
|
| > * marks (that are local to the file) like in 'less',
| > * ie positions in the html file recorded and then activated some way;
| > * Two non-reserved keys are required for this.
| >
| > this probably runs into a problem with the way Lynx treats docs internally:
| > FM -- who did much of the early work on Lynx -- used to remind everyone:
| > "Lynx is not a file-viewer"; also, it's probably not worth  2  keys.
|
|    When viewing large html files (~200 kb) it would be nice to have marks
|  to navigate through the document. There are a lot of such files in the
|  Web - most of them are automatically generated.

I agree.  Such markers would be nice to have, especially when longish,
mostly text-only documents.


| > * floating-point numbers be allowed for INFOSECS, MESSAGESECS, ALERTSECS
| >
| > what on earth for ... (raised eyebrows)?
|
|    "You are already at the end of this document" and more useful
|    "You are already at the first document" seems to last too long
|    for me for INFOSECS=1, invisible for INFOSECS=0 or '-nopause' command
|    switch. I wish I be able to set INFOSECS=0.3.

The standard UNIX/C function sleep(3) only accepts integers for
its argument, which indicate the delay in seconds.


| > * ability to filter from Inet to be passed through user-defined command
| >
| > there's already the EXTERNAL feature: see Users Guide.
|
|   I meant the following: the ability to pass content that is being
|   downloaded by lynx (eg HTML file) to be filtered through some program
|   and then fed to lynx. Preferably such functionality should be activated
|   by user at runtime (by selecting the filter from a set of predefined or
|   by entering command line). For example, filtering through sed can be
|   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
|   can be parsed and interpreted (like document.write). Complex character
|   set translations will also be allowed by this approach.

I can think of some possible uses for such filtering, as well.

Seems like it should be fairly easy to implement, as long as the
filters *are* truly filters (ie, read from stdin, write to stdout).


Of course since you're the one proposing such things, it is probably
up to you to take the next step, and generate some code ...

/kim