vt/ansi codes

[Chuck Swiger]

abc at ai1.anchorage.mtaonline.net wrote:
[ ... ]
>>Do you need color?  Are you using plain text-mode stuff, or do you need
>>bitmapped graphics?  If text-mode, do you need cursor positioning?  Do you
>>care whether your code runs on anything but an Intel box?
> 
> over years of coding, i got fed up with some basic things.
> after 1000's of pages of google-ing, i don't think i am alone.

You don't think you're alone because you've Googled a lot?

> namely, i am not happy with the current selection of text editors
> (i find joe(1) to be very good, but it's got some problems and
> is aging without good development),

136-sec# ls /usr/ports/editors | wc -l
      200

I don't think FreeBSD particularly needs another editor, but you could write 
another one if you really wanted to.  'ee' is probably about as small and 
lightweight as anything you'll find, since 'vi' has gotten fat-- 'pico' and 'vi' 
are both ~250K compared to 50K for 'ee'.

> and i am not happy with the current selection of terminal based browsers (i
> understand mc(1) to be the only real choice).

lynx is a terminal-based browser.

mc appears to be a clone of a product called Norton Commander, which I would 
describe as a terminal-based "file manager", not a "browser".  I wouldn't blame 
you for not being happy with mc, my only question would be why would you want to 
use such a thing in the first place?

> these are critical to me as they things i use probably more than
> anything else.  and i am tired of crazy configuration files.

You're tired of using the shift key to produce capital letters at the beginning 
of your sentences, too.

> and i am also tired of 'broken' terminal stuff like "window(1)"
> and "talk(1)/ytalk(1)" - neither of which do color, and which
> require special termcap tweaks that never seem to work right,

About fifteen years ago, talk/ntalk/ytalk was replaced at CMU by a program 
called zephyr, which was written at MIT: it provided both command-line and 
X-windows based functionality, a list of friends, channels, on/off/hidden 
status, and so forth.  In short, it did everything one might want from "instant 
messaging", unless one prefers to be fed ads while using a program.

[ In which case, AIM, Windows Messenger, etc, await. ]

I've never used window, but screen might do a little better.

> i think in 2003 i should be able to use basic terminal stuff
> with color in a standard/efficient/basic way.  but i admit, i
> could be dreaming.  i'd also like control a terminal from various
> scripting languages (sh/awk/whatever) with ANSI escape
> sequences - things that would be a real "pain/kludge"
> to do any other way.

ZSH has the echotc/echoti commands.  And there's tput:

	tput -T vt100 cl

> anyway i checked out SLang and ncurses, and while i see the good
> aspects of these things, i see many things that i don't like,
> off the top of my head:
> 
> a)  i don't like their size (near half a megabyte for libncurses.a).
>     things like a browser/editor need to be statically linked
>     to use in single user mode.  i prefer things to be useful
>     on old systems/embedded systems/boot+install floppies.

So staticly link your preferred editor.  For something like vi, you can even 
tell it not to link against termcap or curses.

> b)  i don't like their complexities/API.  i don't want to spend
>     more than a few days mastering a fairly complete terminal I/O API.
>     i think a person should be able to program competently within a day.

I've never used SLANG, but it doesn't take very long to learn to use curses.

> d)  neither SLang nor ncurses are available to scripts as ANSI
>     escape sequences are via simple echo/printf statements.

Ncurses (and presumably SLANG) are libraries which are used by C programs to 
link to.  You don't link a shell script, nor do you need to.  Perhaps something 
like dialog might help?

> e)  i assume (with a degree of ignorance) they must be inefficient
>     over slow serial connection just based on the limited vtXXX
>     capabilities of the vt/pcvt and xterm drivers.

Why remain ignorant when you can measure it?  Curses supports a tracelog.

>     since they
>     can't interpret "scroll left/scroll right/scroll regions",
>     screenfuls of data are being sent just to move past a
>     leftmost/rightmost column or to scroll a tiny portion of
>     a display.  this is multiplied with use of color.  for example,
>     if i have a 80x60 color display, that's 4800 chars + 4800 * 10
>     (attribute and color escape sequence/char), or 52,800 characters
>     that must be transmitted - when at most - with ANSI 3.64 scroll
>     left/right sequences - this figure would be 60+60*10, or 660
>     characters - almost 100x faster updating.

Dude, it's possible to misconfigure TERM so that curses has to resend an entire 
screen full of data, but normally curses will take advantage of terminal 
scrolling capabilities.

But don't let that stop you: if you can write a program which does something 
useful and requires two orders of magnitude less bandwidth than curses does to 
accomplish the same thing, go for it.  My bet is that you'll learn enough about 
the assumptions you're making that you'll change your mind, but either way is okay.

> in my semi-ignorant estimation, there is a big problem in
> lack of terminal standardization and vtXXX deficiencies that
> could be very nicely resolved if the "open source" community
> would define and implement as fully functional and complete
> set of ANSI escape sequences that could reliably be used
> across all platforms/terminal drivers within a "raw"
> terminal state.

Someone could change the syscons, pcvt, xterm to implement all of ANSI 3.64, or 
whatever that standard was, sure.  It wouldn't make much difference, for the 
reason you next mention:

> for workstations using terminals that use proprietary ANSI command
> sets - an optional library that re-interprets the I/O of a uniform
> "ANSI superset" could be made available, one which could work
> transparently via the ANSI "terminal ident" escape sequence.

Oddly, that sounds exactly like what termcap/curses does.

> it's just my semi-ignorant humble opinion that a new ANSI standard
> needs to be developed to move UNIX terminals past circa 1977.
> are my grandchildren going to be stuck with vt100 in 2077?

Something better than character-based terminals already exists: bitmapped 
terminals, particularly with something like hardware-acceleration for OpenGL, 
can do a very nice job of rendering text if you turn each character glyph into a 
texture.  There's a lot more the Apple's Aqua than just that, of course.

-- 
-Chuck