On 7/31/07, Peder Stray <[EMAIL PROTECTED]> wrote:
>
> On Tue, 31 Jul 2007, Robert Anderson wrote:
>
> > On 7/31/07, Peder Stray <[EMAIL PROTECTED]> wrote:
> >>
> >> On Tue, 31 Jul 2007, Robert Anderson wrote:
> >>
> >>> On 7/30/
On 7/31/07, Peder Stray <[EMAIL PROTECTED]> wrote:
>
> On Tue, 31 Jul 2007, Robert Anderson wrote:
>
> > On 7/30/07, Peder Stray <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> How can i tell if the screen i am using really understands 256 colors
On 7/30/07, Peder Stray <[EMAIL PROTECTED]> wrote:
>
>
> How can i tell if the screen i am using really understands 256 colors or
> not? i try 'tput 39' both within screen and outside, both actually send
> \e[38
http://www.cs.rice.edu/~scrosby/software/tf256color/src/256colors2.pl
_
e, specifically do a search for "begin a sequence of non-printing
characters" under the PROMPTING section.
Each of your color codes should be enclosed in that type of a sequence.
Robert Anderson wrote:
I use bash and have a custom prompt that includes some coloring (which
includes non-pri
I use bash and have a custom prompt that includes some coloring (which
includes non-printing characters, of course).
When in an xterm, I can always use ctrl-a (beginning-of-line) to return to
the beginning of the line, and it always goes to the correct cursor
position.
When I start screen, if I
Is there any way to scroll back _within_ a split screen? If I use the
xterm scroll mechanism it just scrolls back the whole thing, becaue
obviously it doesn't "know about" the split screen.
I'm looking for an emacs type behavior where the split "buffers"
scroll independently.
Thanks,
Bob
_
