lynx-dev
[Top][All Lists]
Advanced

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

LYNX-DEV Re: External command


From: Al Gilman
Subject: LYNX-DEV Re: External command
Date: Sat, 19 Apr 1997 13:49:21 -0400 (EDT)


  X-URL: http://www.flora.org/lynx-dev/html/month0497/msg00670.html
     
                             LYNX-DEV External command

       * From: Wayne Buttles <address@hidden>
  
  I was thinking about adding an external command in lynx when I realized
  there would be a snag, you wouldn't be able to spawn an external program
  on the result of form data being sent.  I am willing to live with this and
  I was looking for comments on the subject.
  
  I put a sinular feature into bobcat and it is a very handy command in the
  dos world, but it would be equally handy in multitasking systems for the
  following:
  
  highlight a selected link
  press the LYK_EXTERNAL key
  the EXTERNAL:<url_type>:command: takes over
  
  The most relevant command I can think of is wget which is a command line
  html and ftp grabber that can do silent, backgrounded transfers.
  
  EXTERNAL:html:wget -q %s &
  EXTERNAL:ftp:wget -q %s &
  
  This would allow for background downloads.  As I said in the beginning,
  since we can't actually take control of an already open connection (at
  least, I can't), we can't do this for files that are the result of a form.

[Al, here...]  

Can anyone else help with the "capturing the current activity
stream" issue?  In terms of process control, one often discovers
that a fetch is tedious after it is in process.  It would be nice
to be able to do an after-the-fact "Push the ongoing fetch into a
background thread and let me forge ahead, please."

In the case of slow fetches, the user would like to know when it
is done and may well wish to visit the resource with Lynx once it
is local.  This is somewhat akin to what Lynx does now with
temporary files except that the local copy is presumed permanent,
not temporary.  In terms of operation selection, it is somewhat
akin to expanding the operation-application capabilities of DIRED
mode from things that are already local files to things that can
be made local files.

One of the things we would need to work out is how to queue up
the terminated threads so that the user retains control.  In the
case of a background fetch, one way would be to alert via the
status line when the fetch is complete and cache a link to the
new local resource somewhere.  Candidates for "somewhere" include
the existing V)isited_link page or a new Things_you_asked_for
circular buffer or UI page.

I agree with one of the earlier commentors that one operation per
type is insufficient, in general.  This should work more like the
tag-and-operate in DIRED.

Another analogy is Netscape's Right-mouse-button on a selectable 
link.  We want an intervening "OK, what do I do with it?" query
with an extensible menu of options.

This is ambitious.  But it gives some idea of how this fits in
with other things Lynx already does and other things that people
want (like re-fetch through filter).

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