[Top][All Lists]

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

Re: dividers/borders

From: cga2000
Subject: Re: dividers/borders
Date: Sat, 22 Mar 2008 13:15:42 -0400
User-agent: Mutt/1.5.13 (2006-08-11)

On Sat, Mar 22, 2008 at 09:48:26AM EDT, Angel Martin Alganza wrote:
> Hello,
> On Sat, Mar 22, 2008 at 08:06:49AM -0400, cga2000 wrote:
> > Michael said at the time that it would not be hard to implement and
> > asked whether anybody else might want this new feature.
> I'd love to have it.
> >
> It looks very good, but...
> > I think the second screenshot in particular would look a bit better if
> > there was a thin (1 pixel wide?) continuous vertical line clearly
> > delimiting the two halves of the display.
> ...I would even like the space it has now to be thiner, or even
> better, not to have any space between areas at all.

.. but then if you have two similarly formatted texts such as two man
pages there might be circumstances where you would be reading the text
in the left sub-window and your eye would drift to the same line in the
right sub-window before you'd realize you need to hit a "mental carriage

I think some form of separation such as a continuous vertical line
helps keep the display more readable.

> > The nice thing IMO .. is that apart from the number of colors, this
> > makes it impossible to tell whether I'm running screen under X or a
> > linux console.
> I will not be using X most of the time when I have vertical splits and
> a high resolution console, actually. :-) 

It depends what you mean by "high resolution" -- Some modes are
supported out of the box by the generic vesafb driver that's usually
enabled in out-of-the-box kernels .. Otherwise you may have to enable
the framebuffer driver that's specific to your video card, which
normally requires a make config and compiling a custom kernel.

See the "Framebuffer Howto" by Alex Buell.

> Are there any Debian GNU/Linux or Free, Net, OpenBSD packages/ports
> which currently support it?  If not, is it too hard to compile screen
> from sorurce and which version should I try to compile?

Not sure how this relates to the above. As I understand it, screen per
se has nothing to do with resolution. IIRC, the only reason I had to
compile screen from source rather than use the Debian package was to
enable 256 color support and take a look at the new vertical split

But in any case, on a recent Debian GNU/Linux, compiling screen from
source is usually just a matter of reading the doc and once you have
decided what options you need beyond the defaults, if any .. typing
"./configure --options; make".  

As to the BSD's I don't know.

reply via email to

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