Yep, I dont see why we should delegate scrolling to screen. screen is
bloated GNU
software and i dont want to relay on it.
Another random idea for 'st' would be to redirect the IO of the terminal
to a file.
Something like piping shell applications but integrated on X. Like
overlapping buffers
thru different filter applications. This can be useful to grep the
scrolling buffer for
words, or less it, etc.. this will simplify the implementation of the
scrolling by
delegating the task to another application like more/grep/less/nl, etc...
Some years ago I thought it would be possible to hook pipes in runtime
and graphically,
that is, linking the output of a terminal to the input of another one,
and be able to bind
scrolls between them (like in vim:scrollbind). I think that this maybe a
little complex, but
by discussing with more people we can probably reach a decent solution
and new ideas
to play with st.
About the buffer size, its ok to refer as it as in bytes, but st should
keep a pointer
to the beggining of the oldest line, because we would like to keep lines
and not
part of them.
BTW i really like the background-color change idea. I would probably use
it manually
instead of at automatically, but would be good to test.
--pancake
Mate Nagy wrote:
On Mon, Aug 24, 2009 at 02:17:15AM +0200, Valentin wrote:
Isn't that what screen's there for? :P
if only screen's interface for scrolling back wasn't ridiculously
uncomfortable. IMHO shift+pgup/pgdn, and horribile dictu mousewheel
scrolling are essential. On the other hand, regex search forward
backward etc would be convenient, also keyboard-based text selection
(connected to the X clipboard, which again screen cannot do).
Regards,
Mate
