Re: Feature request

Bryan> so, do you have an visions of what a user would have to type to
Bryan> get this?  something like '^EcR4^M' where ^EcR lets you then
Bryan> enter the number multiple (so 4 followed by a return).  then it
Bryan> would display 80 lines?  or, would it be ok to allow the user
Bryan> to set the number of lines the replay function uses?  something
Bryan> like '^Ec=r48^M', meaning ^Ec= starts the setting of a
Bryan> function, 'r' selects the replay function, and '48^M' is 48
Bryan> followed by a return?

I don't so much have a vision of the command line keys, though maybe
I'd go with a semi emacs keybinding of ^Ecp to go backwards (screen -
2) lines, and ^Ecn to go forward the same number.  

>> Since I use 80x48 xterms, the number of scroll back lines works better
>> with 46 lines for me, rather than 60.  

Bryan> would this play into the above?

I was sorta wondering out loud how the numbers 20 (for ^Ecr) and 60
(for ^Ecp) were arrived at.  It would be nice to scale them both by
the size (with a reasonable default of 22 say?) the size of the screen
that console is on.  

Or could we trap ^EcPg_Up and ^EcPg_Dn keys as well to handle this
scrollback?  I use this all the time on my xterms, which have 2000
line buffers.  I just cat large files sometimes (or dmesg output, etc)
and I can move back in history just by hitting Page_Up and Page_Down
keys.  It's quicker and easier than using the mouse to scroll.  

Bryan> i love the idea.  it would be fairly easy to make the number of
Bryan> lines of replay be a variable, and settable by the user.  the
Bryan> playback of a huge number of lines might be a bit more
Bryan> dangerous.  i haven't looked at the code used by the replay
Bryan> function very closely (it's current version was contributed by
Bryan> a user), but it might have to change to support lots lines - i
Bryan> know it does a lot of memory allocations, and might even store
Bryan> it all in memory before writing it out, but that might not be
Bryan> 100% accurate.

The simple way would be to reserve scrollback buffer memory on a
per-console basis, but that's overkill.  Maybe keeping a couple of
buffers around depending on how many console connections there are
would be better.  As people detach, the memory goes back into the free
pool.  So the worst case would be if every console was in use, times
the size of the buffer needed to hold the scroll back info.  

Bryan> you mind if i ask why you'd like to replay so many lines?  i
Bryan> can see where you might need more than 60...i've need that
Bryan> before, but i just go look at the logfile directly in those
Bryan> cases.  but, would you really need more than, say, 2 or 3
Bryan> hundred?  just curious about the usage.

I'd say being able to scroll back 250 by default would be enough, and
maybe let them configure it to a larger number if they want, say 500?
The idea is to not have to login to the console server(s) to find the
log files to go back and see what happened on a console unless
something extraordinary has happened.

It's just been frustrating not being able to scroll back 62 lines at
times to find that one last bit of info, before having to login and
peruse logs.

John
   John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
	 stoffel@lucent.com - http://www.lucent.com - 978-952-7548