On Sun, Jun 16, 2002 at 01:04:34PM -0400, Greg A. Woods wrote:
> [ On Sunday, June 16, 2002 at 15:35:22 (+0200), David Ferlier wrote: ]
> > Subject: Re: patch for wscons scrolling
> >
> > I finished doing it this way, this means that you can have something
> > like this in your keyboard map :
> > 
> > keycode 208 = Cmd_ScrollDown Down
> 
> Very nice!  Thanks!
> 
> I presume the "Cmd_scrollDown" has to be explicitly cancelled by
> pressing the ScrollLock key again and that until then the other selected
> keys can do other scrolling operations (eg. "Up", "PgUp", etc.).
> 
> What is the behaviour of the screen when the "hold screen" mode is
> turned off?  Does it revert to the most recent output as does FreeBSD?
> (I think that's what it should do -- it seems it would be the most
> predictable and un-surprising behaviour.)

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 ?

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

> 
> (What's prevented me from getting frustrated on FreeBSD has always been
> the glow of the little scroll-lock light to remind me why most keys are
> not responding.  If that LED were not there or were not working then I
> really would want Xterm's 'si' (scrollTtyOutput) and 'sk'(scrollKey)
> options so I could choose my preferred behaviour -- i.e. make it match
> the way I normally use xterm, which is of course "-si -sk".)
> 
> 
> > ( if nobody understood, sorry but it's hard to explain something
> > technical (or not ;-) in another language than french ;-)
> 
> I'm sure it is -- I have a hard enough time in my own native language
> sometimes, and I'd be pretty much useless in any other language, even
> French even after five years of high-school classes since that was all
> too many years ago now with no real practice since.  You do very well
> indeed in English!
> 
> -- 
> 								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>
> 

-- 

Run NetBSD    - www.NetBSD.org
David Ferlier - krp@freeshell.org