lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev proposal for LYK_SCRIPT and patch


From: Eduardo Chappa L.
Subject: Re: lynx-dev proposal for LYK_SCRIPT and patch
Date: Wed, 30 Jun 1999 22:52:25 -0700 (PDT)

*** Henry Nelson (address@hidden) wrote on Jul 1, 1999:

:) One thing I am not clear on yet is whether or not the original, cached
:) source is left intact.  If it is, then there is no problem.  However,
:) if the cached source is irrevocably changed by the script that is applied
:) to it, i.e., you cannot go back to what was there before running LYK_SCRIPT,
:) then I think you should work on finding some way to create a new document
:) and access that.

  No, the cached source is not left intact. You have to change exactly
that document and make it the output of your script. Although I understand
the actual source is necessary you may back it up before applying the
script and make one of the options of the script to recover the original
source (so you make a two pass by the script). This however will not
recover the http reference in the original file, it will always be a
file://localhost reference, which is for me more bothersome actually,
because it makes you write more code for the script to work, but it's still
doable, not in the right way though.


:)  There are two reasons: 1) a person may have "pushed the
:) wrong button", chosen the wrong script, and 2) for unknown pages, a person
:) may want to experiment with what he has in his toolbox.  (This is what I
:) do in reality now: come in "from the side" [go into another screen], run
:) scripts on a copy of the document until I have what I want, then write over
:) the document TMP file, jump back into Lynx and do a ^R.)
:) 

  The first question you are asked in lynx when you activate LYK_SCRIPT is
if you want to change the /tmp file after you apply the script. Although it
may sound redundant to ask such a question, my script did not sometimes
made changes to the source but rather was a help to help me "see" something
through an external program (so I was using LYK_SCRIPT as EXTERNAL was
originaly meant to work). Also one of the options of my scripts at the
beginning and at the end is to exit the script. Of course, if you applied
the wrong script, there is no undo (at this time, although it is certainly
a good idea, and could be implemented rather easily.)


:) If I could make one request, it would be to couple the LYK_SCRIPT function
:) to the --enable-source-cache configure option.  The main advantage I see to
:) LYK_SCRIPT is that it uses the cached source.  Someone who does not want to
:) have the source cache most likely is not going to feel a need for LYK_SCRIPT.
:) Mostly this ties in with what Philip hinted at yesterday or the day before
:) that lynx.cfg is getting unwieldy.  Other than having it or not having it,
:) I can see no need for configurability.
:) 

  I though a bit about this, and it is tied somehow. There is no way you
are going to get it to work without EXTERNAL configuration, and only in the
case where you cache your source you will pass $2 as the /tmp file,
otherwise nothing gets passed, so the way I see this is that LYK_SCRIPT is
more an external command, than a cache_source configuration. This is
changeable though, if other people agree that LYK_SCRIPT should not work
unless cache_source is also true (essentially external command and
lyk_script are the same if you don't cache the source). I also agree no
need of configurability

  I am thinking of ways to improve the implementation and your
suggeestions are very valuable to me. Thanks a lot for your feedback. I
think I have ideas now of how to do this to satisfy your needs.

Eduardo
http://www.math.washington.edu/~chappa/personal.html


reply via email to

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