On Wed, Jun 04, 2003 at 09:22:05PM -0700, Soren Jacobsen wrote:
> On 06/04 22:58, Richard Rauch wrote:
> > Instead of installing 3rd party software, you can scroll on the
> > console with window(1).  This ships with NetBSD so you don't need
> > access to the package collection, nor to build anything.  It's also
> > Berkeley-licensed rather than GPL'ed.  (^&
> > 
> > window and GNU screen are not exactly interchangable, but they do
> > similar things: Scrolling, cut'n'paste, multiple windows on a text
> > console.
> 
> Window definitely needs some (a lot of?) work before I'd start replacing

...depends on what you want to do with it.

For what was originally requested (scroll-back), window works every bit as
well as screen AND it comes bundled with the base system (no need to go to
pkgsrc).

When I was toying with both a few years ago, I came to the conclusion that
each had some advantages that the other lacked, so the choice between them
seemed more of a toss-up.


> screen with it. You were planning on making some improvements, right?
> What's on your TODO?

Yes.  The first step was to put a suitable, basic termcap entry into our
termcap database.  That way if you ssh into a NetBSD system from a window
environment, things will still more or less work.  (Unfortunately, the way
that window works, it doesn't have a well-defined terminal type; it depends
upon your real terminal's capabilities and a local TERMCAP variable is
written.  This would be fine, except that ssh, for some bizarre reason, exports
TERM but not TERMCAP...)

Julian Asange, if memory serves, updated the termcap database for that, at
my request.


The next step got postponed by not having a machine for me to run -current
on.  (^&  But now that excuse is gone, so I'm looking at it: Rewrite window's
wwwrite() function to use a *real* terminal type as best it can, rather than
a fictitious one.  The intent is that even if you ssh into a non-NetBSD system,
the TERM variable should still bind to a real termcap entry.  The termcap
update for old window-v2 would then only be a "legacy" feature.

For now, it will probably do to emulate a fixed terminal type (as GNU screen
does, I think).  Ideally, there should be at least two types (say, VT100 and
VT220), or it might even be possible to export TERM as whatever the real
underlying TERM is (well, I'm sure that it's *possible*; I just don't know
if it's worth the work).


Another item on the list is to implement some actual new features, such as
the ability to reconnect a session as GNU screen allows.  (Any other features
that are missing?)  Probably after getting a first pass at modifying wwwrite(),
but before doing anything too fancy with terminal emulation.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/