[ On Sunday, June 16, 2002 at 20:18:33 (+0200), David Ferlier wrote: ]
> Subject: Re: patch for wscons scrolling
>
> in fact, it doesn't care of the last output : it always scrolls down
> to the last line. Should i modify that to take care of whether new
> output was written while the screen was being holded ?

Obviously output to the console should never be lost while the "screen
window" on the buffer is scrolled back to show older output in the
buffer, and I don't believe output should be held either.  The system
should be immune to an operator leaving the screen in "scroll-mode".  As
such any new output should never remain hidden when the "scroll mode" is
released (so yes, it should jump back down so the newest line of output
is at the bottom of the screen).

My preference would be that while in manual "scrolling mode" that output
not cause the screen to scroll unless it is necessary to do so because
the currently displayed portion of the buffer is being rotated/forced
out of existance by the new output.  I.e. if the screen is displaying
the beginning of the buffer and new output forces the currently
displayed output to be deleted from the buffer, then the view on the
screen must stay at the beginning of the buffer and the displayed text
will appear to scroll.  Remember that the screen will eventually be
forced to the top of the buffer by new output even if it isn't left
there by the operator, so this feature is a necessary evil if we want to
avoid having systems be frozen in place by being left in scrolling mode.

If my memory isn't playing tricks on me this is the way FreeBSD
currently works (though I'm not 100% certain and I don't have a machine
locally to test on at the moment).

The alternative is of course to simply leave what's on the screen there
and to do nothing when the original data in the buffer is rotated away,
and only reveal to the operator that this has happened when the next
scrolling event is signalled by a key press.  However to me this would
be very disconcerting -- suddenly the screen might jump to newer output,
even brand new output, without giving any indication this has happened.
This wouldn't be so bad if there were a scroll-bar to show the jump of
course, but without a scroll bar I think the sliding window effect
should be kept as intuitive as possible.

(One other issue is what to do about cursor movement escape sequences
and such.  I'm not sure how wscons interacts with the console buffer --
my preference would be that the buffer be a raw record of all output and
that wscons simply do its best to interpret the buffer from a given
start point which will normally be the first character after a newline
if the finest-grain scroll command be to move one line at a time.)

> > > Another thing, i 'm quite sure of the answer, but i can still ask. Say
> > > we are in mode hold screen, all keys typed go in a buffer, and this
> > > buffer is drawn when going back when you hit hold screen again. Let's
> > > say the Cmd_ScrollUp command is put on the Prior key (Pgup on a
> > > keyboard who has it). Each time he hits the key activating the scroll
> > > command, do we want to prevent the keycode from going through the rest
> > > of the wskbd_translate function ?
> > 
> > Yes I think that would be best to block other keys while in the "hold
> > screen" mode.  For a sophisticated xterm user it can be surprising not
> > to be able to type when the screen is scrolled back (and of course there
> > are several user-selectable options to control xterm's behaviour in this
> > situation) (I've been surprised in this way several times when using
> > FreeBSD).  However on the console it seems prudent to only supply the
> > safest option -- it would be even more surprising if those keystrokes
> > contained (especially by accident) some destructive command and there
> > were no way to erase them from the buffer before you released the "hold
> > screen" mode!
> 
> wait wait, i knew i wasn't clear ;-) I don't want to modify the whole
> behaviour of the HoldScreen key. Keys that don't activate scroll
> up/down should still be sent to the buffer right ? i just want to
> block the ones that activate scroll up/down. i won't make two modes
> for that.

No, when the "ScrollLock"/"HoldScreen" key is first pressed the screen
should now be held in position, displaying the currently displayed
portion of the buffer (until it is forced to scroll if new output pushes
the current display right out of the buffer as I discuss above).  Until
the next keypress of the same "ScrollLock" key, no keys will have any
effect at all except those that are chosen to implement scrolling
actions (eg. Up, Down, PgUp, PgDn, <CTRL-N>, <CTRL-P>, <ALT-V>,
<CTRL-V>, 'j', 'k', <CTRL-F>, <CTRL-U>, etc.).  During this "hold
screen" mode the "Scroll Lock" light on the keyboard should be lit
(assuming there is one).  Maybe any other keypress should also cause a
beep to be signalled if possible just to remind the operator those other
keys are are being ignored.

(I keep assuming that when you're talking about key presses that you're
talking about the keyboard buffer -- i.e. operator input ready for
whatever's reading /dev/console to read.)

I think that any optional mode which behaves more like xterm, with a
direct key combination invoking a scrolling action, should be a
"temporary" scroll mode -- i.e. that the screen should instantly revert
back to the newest text in the buffer when the keys are released.
Eg. The operator would press <CTRL-SHIFT-PgUp> to initiate the
scroll-back, then while holding <CTRL-SHIFT> repeat the <PgUp> or <PgDn>
or <Up> or <Down> keys to move around, but when both the <CTRL-SHIFT>
keys are released then the screen would immediately return to the most
recent output in the buffer.  The option of course is to go all the way
with Xterm functionality and implement 'scrollKey' and 'scrollTtyOutput'.
options for wscons as well (the defaults for which I think should be
equivalent to invoking "xterm -si -sk").

I personally greatly prefer the FreeBSD-style scrolling to Xterm's
keyboard scrolling controls though.  (I really dislike Xterm's handling
of new output by always moving the screen window.  Hmm.... I wonder how
hard it would be to implement FreeBSD-style console scrolling in Xterm?)

Perhaps you should endeavour to find a machine on which you can install
a recent release of FreeBSD (_and_ any other OS which has this feature)
and play with it so you can have a working reference to what I'm trying
to describe.  :-)

I don't necessarily want exactly FreeBSD's behaviour to be copied though
-- I'd rather see it improved slightly, especially if it actually does
not exactly match what I'm saying here.  I'm trying to describe what I
think would be ideal behaviour -- or at least some of the key points
that I think are necessary features (regardless of whether FreeBSD
implements them now or not).  (For example so far as I know FreeBSD does
not currently implement Xterm-like scrolling, and though I don't prefer
xterm's behaviour, others do seem to.)

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