lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV webtechs download form


From: Benjamin C. W. Sittler
Subject: Re: LYNX-DEV webtechs download form
Date: Thu, 30 Jan 1997 13:23:07 -0700 (MST)

On Thu, 30 Jan 1997, Eli's redistribution point wrote:
> Benjamin C. W. Sittler <address@hidden> wrote:
> : I frequently use screen (I am right now) and have Lynx setup to open in a
> : window all its own. I would like to enhanced support for screen (and other
> : similar systems, such as splitvt) that allow virtual terminal multiplexing
> 
> I am not familiar with that, where can I get information? Would anyone
> here be able to test something written with that? Of the shell
> multiplexers I have used (shl, screen) neither provides good support
> for programs to do this on their own. I don't think shl can do it
> at all, screen requires that you run screen and have it do everything.
> That's simple to code, but limited in power. fork/exec/(fork?/)exec
> is going to trash a lot of the environment, eg what file descriptors
> are open, and the contents of dynamic memory.

splitvt is the simplest terminal multiplexer of all... it splits the
screen into two panes and can run a different program in each window. It's
probably to braindead to be truly useful for Lynx, since you have only 50%
of your screen left for each program. It would certainly be possible to
have a single program be effectively present in more than one screen, but
it would require either (a) a rewrite of Lynx that understood screen's
methods of interaction (it's done using a unix-domain socket) or (b) a
dumb lynx display client that basically acts as another terminal connected
to the same Lynx. The latter would actually be more general, since it
would make Lynx instantly capable of spawning multiple views in X, MGR,
screen, or even Linux virtual consoles, with all the window
system-specific code confined to shell scripts. This seems a mite too
ambitious.

> : and persistent sessions. Perhaps a general way to achieve this would be an
> : `alternate viewer' hotkey (similar to the Printer list) that allowed the
> : opening of either the current link or the current document with another
> : program. This would be great for those of us (for example) that like to
> : play with gopher, but don't like the way Lynx implements it (it's not
> : Gopher-plus compliant.) Perhaps a more general solution would be to allow
> : a third `%s' in a printer or downloader definition which gets replaced by
> : the URL of the resource in question.
> 
> Yeah, I think there are good arguments for allowing lynx to use more
> helper programs rather than having everything built in. That is a
> seperate issue from screen, but it would be good to have screen support
> for that stuff. I would much rather read news with trn than lynx, and
> I would rather use Rnmail than lynx's internal mailer.
> 
> Possibly the configuration file could be expanded for XWINDOWS/
> SCREEN/NON_(X)WINDOWS environments with HELPERs for various schemes.
> specified. That way people could use one mailer in X ("toolwait mailtool")
> and another in screen ("screen elm") and a thrid in a non-windowing
> environment ("lynx_internal").

I would prefer keeping Lynx simple (by not tying it to any particular
windowing system) and placing the intelligence in shell scripts, a library
of which could be included with Lynx.

If anyone's interested in pursuing this, I have a shell script that will
run a program in another window (if a windowing system is detected) or on
the same tty (if one isn't.) It currently supports X (xterm), SunView
(shelltool), and screen. It should be easy to extend to other
windowing/terminal multiplexing systems.

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