Arch Linux

dsulli99

Member

Registered: 2010-11-18

Posts: 31

Question regarding GNU screen copy and paste buffers

Ok, I think this should be an easy question to answer but I'm kind of stuck.  Basically I'm trying move to a primarly mouseless computing experience.  I'm trying to use the copy and paste/buffering capabilities of GNU screen to avoid having to actually highlight blocks of text with the mouse.  I understand that this is a pretty standard feature of GNU screen, and from what I've googled it looks like a decent amount of people are using it.  My problem is that I am trying to copy text that has a more than a screen of scroll-back.  when I enter copy mode by pressing cntrl+a, [, it starts the buffer at the current character position.  What I would like to do is go to the very TOP of the buffer so I can highlight the first character, then go to the very BOTTOM of the buffer and hit space bar again (to copy everything in the buffer).  To go to the top, I type 1G, which moves to the top of the buffer.  The problem is that this has a BUNCH of blank lines in it (my screen buffer is set to 10000 lines, and I only have let's say 1000 lines of input).  What I would like to do is go to the first line of input, not the first line in the buffer.  I want to avoid copying all of the blank lines at the top of the buffer.  Does anybody know a keyboard shortcut to go to the first line of input in the screen buffer, or an easy way to strip out all of the leading blank carriage returns in the buffer?

Thanks,

Dan

keenerd

Package Maintainer (PM)

Registered: 2007-02-22

Posts: 647

Website

Re: Question regarding GNU screen copy and paste buffers

Most vim motions are supported.  If regex search worked, "^a [ ? ^$ "  would search backwards to a blank line.  But it does not.

However, I did notice that the dead space before the term is always the same, and is always equal to the height of the term.  So "73G" takes me to the first real line.  This is a little hackish.

dsulli99

Member

Registered: 2010-11-18

Posts: 31

Re: Question regarding GNU screen copy and paste buffers

Hi, Keenerd,

Thank you for your reply.  The hackish solution you posted doesn't actually work.  73G will always return you to the same position in the  buffer, but the postion of the first line of text actually depends on how much of the buffer you've actually chewed up.  If you press enter a few times to shift your utilization of the buffer you will see what I am talking about.  Once the buffer is completely full, 1G will return you to the first line of text in the buffer.

Thanks,

Dan

keenerd

Package Maintainer (PM)

Registered: 2007-02-22

Posts: 647

Website

Re: Question regarding GNU screen copy and paste buffers

Oh.  Sorry.

Almost found another way.  Pressing ^a i  returns some info.  (screen rows, cols)/(buffer rows,cols)+buffer size.  buffer rows looks like it never changes, which is unfortunate.

One idea that might work.  Screen is really scriptable.  You could make a script that copies the first line of the buffer, checks if it is blank, and keeps looping through until hitting a non-blank line.  It drops a mark there and gives control back to you.

dsulli99

Member

Registered: 2010-11-18

Posts: 31

Re: Question regarding GNU screen copy and paste buffers

Yeah, I saw the ^a i, it does provide some helpful information.  The scripting solution you provided seems a little bit complex.  I am not sure if I want to tackle passing control back and forth in this particular issue.  I think what I am going to try to do is just do 1G to go to the top of the buffer, then just search forward using / for the first line that starts with a non-whitespace character.  This is kind of the inverse of what you propsed before.  I haven't had a chance to test this but I will let you know if it works.

Thanks again,

Dan

dsulli99

Member

Registered: 2010-11-18

Posts: 31

Re: Question regarding GNU screen copy and paste buffers

This works if you do cntrl+[ to get into copy mode, hit g to go to the top, then w to go to the next word (first word).

Thanks,

Dan