screen-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hard status line in vertical split mode.


From: cga2000
Subject: Re: Hard status line in vertical split mode.
Date: Thu, 20 Sep 2007 05:02:05 -0400
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Sep 19, 2007 at 11:11:53PM EDT, address@hidden wrote:
> Greetings,
> 
> On 9/19/07, cga2000 <address@hidden> wrote:
> >
> > To copy a 10x5 cells rectangle starting at col. 20 somewhere near the
> > middle of your screen try:
> >
> > C-A [ M 20l <space> c 10l 5j C <space>
> 
> Copying into the buffer isn't too much of a problem. It is pasting
> that is throwing me. I need to take the contents of the clipboard and
> paste into a rectangular area. The clipboard contains multiple lines
> separated by \n. I expect that if I am at row 10 col 20 and I paste a
> 10x5 cell rectangle, that I should see my newline delineated paste in
> 10,20 through 15,30 ....

Don't know if if this makes any sense, but is this absence of rectangle
pasting the result of a "design choice" of screen?  Since screen can do
the selecting & copying of rectangles, it superficially stands stands to
reason that it should likewise be able to do the pasting in the same
fashion.  Right?

In what circumstances would this capability be useful?

You mentioned "a great need" to perform rectangle copying/pasting.

Are you pasting to the 3270 host or to your work station?

This is naturally different from the 3270 environment mentioned below
but in vim, this is how I sort of "simulate" the pasting of a single
rectangle half way down my display starting in column 20:

:set paste
:set ts=20
:set autoindent
M
i
tab
C-A ]

Resulting in all five lines being neatly aligned at col. 20 of my
display.

Naturally things become rapidly impossible when dealing with multiple
rectangles at different offsets .. but then, vim is a programmer's
editor .. not a typesetting engine.

How does the screen paste mechanism work?

The example above tends to suggest that the actual printing to the
screen of the buffer's contents is handled by vim rather than screen.

In any case, vim's display belongs to vim .. xterm's belongs to xterm or
whatever is running in the xterm.  That screen should be able to change
the contents of the display sounds like (1) bad manners & (2) doomed to
fail, since screen shouldn't have a clue what's running in a given
window and how it's currently handling the display (full screen, line
mode, cooked vs. raw mode .. et al ..)

Am I right assuming this?

> What I'm actually seeing is that the newline sends screen(c3270) back
> to the real start of line. 

Is it really screen that does that .. See my speculations above.

It's been a long time since I touched anything that ran 3270 ..  In a
TSO/ISPF editing session, I do remember you could use soft tabs vs.
hard tabs, the former being IIRC handled by the host while the latter
were handled by the 327x terminal..  And that's about it .. Never done
any 3270 programming, though .. So I have no knowledge of the lower
layers.

> I'm surprised there are no mainframers on here that haven't solved
> this already.. :-)

I for one would be curious to know what you are trying to achieve.  I've
always wanted to set up an MVS emulation on a PC so I could IPL like in
the good ole' days.  

cga




reply via email to

[Prev in Thread] Current Thread [Next in Thread]