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, 13 Sep 2007 23:01:04 -0400
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Sep 12, 2007 at 12:31:58PM EDT, Michael Schroeder wrote:
> On Tue, Sep 11, 2007 at 11:22:24PM -0400, cga2000 wrote:
> > I had a couple more questions about vertical split & caption/status
> > lines:
> > 
> > 1. After I do a vertical split, paging or searching is very slow on my
> >    machine. Is this something to do with my configuration?
> 
> No, it's because terminals support scrolling for horizontal splits
> ("scrolling region"), but not for vertical splits, so screen has
> to do lots of redrawing. Xterm provides a "box copy" feature that
> would help a lot, but it's turned off in the default configuration.
> Dunno why...

Is this something you saw in the XTerm code?  How would it help?

I am all the more curious since this slowness in vertical split screen
mode is the one problem that might deter me and presumably others from
using it on a regular basis.

> > 2. Now that we have vertical split, shouldn't we have "focus right" &
> >    "focus left" commands, that could be bound to "h" and "l" for
> >    consistency with "j" and "k"?
> 
> Sure, those aren't hard too add.

Thanks for the confirmation.  I couldn't find a 4.00.03 man page so I
tried my luck binding "h" & "l" to "focus left" and "focus right" and
found it didn't work.

> > 3. Since I've managed to squeeze everything I need into the hardstatus
> >    :-) line, I would be in favor of having a "caption never" option
> >    added. I defined a "caption splitonly "%{+d kk} " so as to have an
> >    empty and mostly invisible line but it does waste a bit of space and
> >    it does not look quite right especially with vim or mutt that already
> >    use up a few lines at the bottom of the screen for their own
> >    purposes. I don't suppose I could get rid of the caption line at this
> >    point?
> 
> Hmm, wouldn't be that hard to implement. Any more users requesting
> this?
> 
> > 4. The vertical band that separates "windows" in vertical split mode.
> >    Is there any way I could suppress it or make it less conspicuous?
> 
> Not yet. Would you prefer a '|' instead of the reverse space?
> (You can change the color with the "sorendition" command, i.e.
> "sorendition 00 70" for black on gray)

Thanks!

sorendition =7 70

... actually suppresses it.

Not sure if it's only in my environment but specifying a caption line
with the following attributes also adds a 1-pixel (?) horizontal line
between the hardstatus line and the caption line:

caption always "%{+d wk} %3n %t "

Here's a couple of screenshots for your review:

http://www.geocities.com/fcky1000/fcky/screen0.png
http://www.geocities.com/fcky1000/fcky/screen1.png

The second screenshot in particular shows a configuration where having a
'|' instead of the 'reverse space' would be quite an improvement over my
sorendition trick. And this is still rather tidy.  With messy stuff like
log files etc. a visible separation does makes things a bit more
legible, I think.

> > 5. Is it possible to split the screen and display the contents of
> >    another window in a single action?  Right now I'm on window #2 and I
> >    would like to see what is in window #5 next to what I have in window
> >    #2.  What I do is C-A |, C-A Tab, C-A 5. Is there a better way?
> 
> Not yet. You can do that with an eval statement, though, but adding
> a "and select in new region" option to the "split" command is
> probably the way to go.

I haven't had the time to look at "eval" yet but thank you very much for
pushing me in the right direction.  I'm sure there are lots of examples
in the list's archives.

> > 6. The screen manual states that:
> > 
> >    "Colors are coded either as a hexadecimal number or two letters
> >    specifying the desired background and foreground color (..)"
> > 
> >    I haven't been able to find the syntax for coding these hex numbers.
> 
> It's just the ANSI colors:
> 
> 0-7: black, red, green, yellow, blue, purple, cyan, gray.
> 8-f: same colors, but in "bright" mode. f is white.
> 
> So "70" means black on gray, "71" would be red on gray.

Oh well.. I was thinking whole bytes I guess .. so I tried everything
from x00 to x0F without success. 

> >    Is there any reason I would want to do so?  Would they provide
> >    additional functionality?
> 
> Nope, same functionality.

I did also try values between x10 & xFF .. just in case. 

:-)

Thank you very much. 
cga




reply via email to

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