[ On Monday, June 17, 2002 at 16:46:54 (-0400), der Mouse wrote: ]
> Subject: Re: patch for wscons scrolling
>
> > My preference would be that while in manual "scrolling mode" that output
> > not cause the screen to scroll unless [...] the currently displayed
> > portion of the buffer is being rotated/forced out of existance by the
> > new output.  [...] this feature is a necessary evil if we want to
> > avoid having systems be frozen in place by being left in scrolling
> > mode.
> 
> Not quite.
> 
> It would also be possible to _never_ disturb what's being displayed.
> In the circumstance you describe, there would then be a ringbuffer of
> output scrolling, plus one screenful frozen for display.

Yes indeed and I think I mentioned that alternative in another paragraph....

> Of course, this then calls for some interface design thought to figure
> out what to do when you scroll after having reached this state.

That was my point in the other paragraph -- with a scroll bar it's easy,
but the forced scrolling when the buffer is full seems, to me at least,
to be far more intuitive (and it shouldn't bother those who like xterm's
behaviour very much since xterm always scrolls the display as output is
received, no matter where it's scroll bar is positioned!  ;-)

I always think of these scrolling things like a literal scroll behind a
small window.  In this case though it's not a scroll so much as a belt
with a wiper on the bottom roller just below the stylus that writes new
text on the belt.  When there's no scroll-bar indicator to show me where
the window is relative to the wiper I'd rather the window be a literal
window and not a copy of what was at some position on the belt at some
point in time.

I suppose a scroll bar could be simulated on most wscons-capable console
devices, but that seems like it would be over-kill.....

> The major benefit of this, to me, is that you can scroll back and leave
> something of interest displayed, and it will never get scrolled into
> nonexistence.  Whether this is something enough people care about to
> bother with, never mind being worth the additional code complexity it
> would call for, is of course another issue.

True enough.  I'm not sure how "major" a benefit this feature is though
in light of the inhernent UI problems it creates.  Even on my SS-1 or
Sun-3 with a bwtwo display and 120x52 characters on the screen I can
probably afford enough buffer memory to keep what I'm looking at in view
long enough to transcribe it, even if some device driver is continually
chattering about an ongoing problem (that's unrelated to what I'm trying
to transcribe).

a sudden spew of output though could wipe the whole buffer no matter how
big it is.....


Hmm.... featuritis, but what about a "snap-shot" action that took the
static frozen copy of the screen you mentioned so that it could be
viewed indefinitely?


(I'd like to play with wscons on a low-end sparc or sun3, esp. with bw2,
but it appears that'll still take a small amount more programming....)

> I also think it would be good to distinguish between "not scrolled" and
> "scrolled back by zero lines".  Both display the same screen contents,
> but the former scrolls when a newline is printed, whereas the latter
> doesn't (any more than if you'd scrolled back it would scroll on
> output).

That's what the scroll-lock light does....  (and in scroll-lock mode,
what the beeping of non-action keys can do too)

(but then again there's this possibility of a scroll-bar that does all
of the above and then some! :-)

> But this is all armchair quarterbacking. :-)

and it's not even football season -- unless you're a soccer fan, but
then you wouldn't be a quarterback!  ;-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>