"Alf P. Steinbach" <
alf.p.stein...@gmail.com> writes:
> So, how practical/impractical is it wrt. implementation for Unix-land,
> e.g. in terms of ncurses? I'm thinking, maybe ncurses can't turn off
> automatic line wrapping or automatic scrolling, or maybe all necessary
> info isn't available. Or maybe (I seem to remember) different colors?
This kind of question might be better asked in comp.terminals.
I don't think line wrapping or scrolling will be a problem.
In ncurses/tty/tty_update.c, the PutCharLR function has three
different ways to place a character in the lower right corner
without scrolling, depending on the capabilities of the terminal.
In some (presumably old) terminals, the function just gives up
and does not display the character.
In software-only terminals like xterm, I think you generally have
a palette of 8 or 16 colors that you can use as foreground or
background colors in character cells. In addition, there may be
a default background color (perhaps mapped to a background
picture rather than a solid color) and a default foreground
color. The bold, italic, underline, and crossed-out attributes
may be displayed as is or mapped to colors. xterm also supports
RGB foreground and background colors in each character cell but I
don't think the terminfo database and the ncurses library support
that. Your _Color::operator|= does not seem reasonable with
default colors and RGB colors, but perhaps you can just not use
those features.
Do not assume you can ask the terminal what the current
foreground and background colors are. Anyway, that ability
doesn't seem important for a full-screen program that sets its
own colors.
ncurses can get the size of the terminal from static information
in the terminfo database, from environment variables, or from a
nonstandard ioctl call. This last method also correctly updates
the size if the user resizes an xterm window while the program is
running. In contrast, if there is a hardware terminal connected
to a serial port and the user switches it from 80-column mode to
132-column mode, the program is unlikely to understand what
happened.
I don't think I've ever used a hardware text terminal that
supports colors or Unicode. Instead, there may be one character
set for Latin-1 and an alternative character set for line-drawing
characters, and the program needs to switch between them. The
ncurses library supports the A_ALTCHARSET attribute for this.
> struct Point { int x; int y; };
>
> inline auto operator+( Ref_<const Point> a, Ref_<const Point> b )
> -> Point
> { return Point{ a.x + b.x, a.y + b.y }; }
Some other libraries use different types for points and sizes,
so that one can add point+size but not point+point. I don't
know whether that actually helps prevent any bugs or is useful
for overloading.
The Ref_ stuff is just confusing. At first, I assumed it was a
separate type like std::reference_wrapper, or perhaps you defined
it differently in debug vs. release configurations. But then you
use it in places like
> One_at_a_time( Ref_<const One_at_a_time> ) = delete;
where it has to mean an ordinary reference; otherwise it wouldn't
delete the copy constructor as intended. Ref_ just makes the
code look strange and thus harder to read, as if you were using
<% and %> instead of braces.
> inline auto union_of( Ref_<const Rect> a, Ref_<const Rect> b )
> -> Rect
> {
> return Rect
> {
> { min( a.x1(), b.x1() ), min( a.y1(), b.y1() ) },
> { max( a.x2(), b.x2() ), max( a.y2(), b.y2() ) }
> };
> }
Perhaps that should check for empty rectangles and not let their
coordinates affect the result.