vt/ansi codes

[abc at ai1.anchorage.mtaonline.net]

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

heh :)

> > 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

yeah, 200 - great :)  tried all of them ...
i've been using FBSD for almost 10 years, since
version 1.X (1995 or so?).  and the same old rebuttals
continue - with no real advance.  "look - 200 editors".
heh (in good humor) :)  more of my favorites are:

Q.  i want to know how to write to the display like i used to in DOS ...
A.  UNIX is not DOS.  what a stupid question.  have a nice day.  goodbye.

heh.  or:

Q.  isn't there an editor for non-gurus to use to set up a system?
A   try vi, you'll like it, it's smarter, better.  if you're too stupid
    to use vi, you're too stupid to use this OS (pre-ee days :).

heh.  i have used vi, and i did learn it, and IMHO, it still sucked
because whatever i could do in vi in 10-20 keystrokes of crypto,
i could do in 2-3 mnemonic keystrokes in joe.  plus, i could
do even more stuff in joe that i couldn't do in vi.

of the 200 editors, most are either graphic apps, vi/emacs clones,
or total pieces of garbage - they really need to be "weeded out".
and the various language specific stuff should really be in their
own trees.  i would guess people looking for a Korean text editor
don't want to wade thru Japanese editors, and people looking for
plain ascii editors don't want to wade thru gobs of Japanese,
Korean, and graphic editors.

my point is things need to be rethought.  redone.  reworked.
and the failure to do so is crippling OSOS's (Open Source OS's).
and all OS's in general.  my specific point (as an example) was
that if a decent fully functional ANSI escape sequence standard
was adopted by all terminal drivers - cross platform code would
be much more efficient in size and CPU time with less dependencies,
much easier to maintain and port, accessible by ALL programming
languages in the same way, displays would look nicer, much more
useful and interesting code would be developed, and i don't see
or hear an intelligent reason not to do so.

and the same goes for FS hierarchies and many other things,
and all the configure/libtool/automake/pkgconfig stuff.  people say
"oh it's great, more stuff to do more stuff on more things".
but after this tree of "more stuff" grows a while, "hello world"
becomes a complication where one has to hack termcap, ncurses,
termios and sys/ioctl; and then configure/libtool/automake/pkgconfig,
and then figure out numerous OS packaging schemes.

all opposing arguments are to the effect of "what about
using this library, and what about this hack and that hack".
forget it - people only have so much time in life.  a goal
should be to create OS's that allow effective and efficient
and lasting creation - not endless and fundamentally pointless
years of study to climb mountains around bad foundations.  "extended
regex's" should be standard - things like "sed -E" and "grep -E" and
"find -E" and all this nonsense needs to go.  it's causing more hours
of "pain" dealing with the nonsense than it would have caused
to simply say "starting January 1, 2002, sed/grep/find will all
link with extended regex libraries - please update any scripts".

and further continuation should be shunned.  IMHO, there's too much
consideration given to compatibility with ancient code sitting on
obscure PDP mainframes with VT100 terminals, and far too little
consideration given to the evolution of quality technical product
(i don't know anything about kernel developments, this is only
a "engineer with a programming/OS hobby" viewpoint).

and that's why in the MS windows arena you find countless more
quality programs and software.  cuz those same programmers in the
UNIX world would quit before completion of any project due to the
endless and pointless overhead and mundane incompatibilities and
nuisances across UNIX platforms.

in UNIX, arguments (more or less) come down to "AT&T did such and
such in 197X", so therefore ...  bunk.  if AT&T (or DEC, et al) did
something lame (compared to todays understandings/technology) in 197X,
it's really not a good reason to continue with it.  it's past time to
do things better than AT&T (or DEC et al) did them in 197X.  methods
should evolve more and more on technical merit and less on ancient
history or however SUN/IRIX does it (remaining backwards compatible
when not in danger of creating a real kludge); and driven with the
goal of a "more intelligent/higher quality" product that evolves
without regard to marketing hype and schedules.  if a programmer is
gonna spend time and work in the open source arena, that should be
(and is) a major justification - what else?  (albeit, many are
driven by socialistic/anti-MS energies).

the open source community as a whole has power to lead and forge standards,
and to continue to follow blindly in the proprietary footsteps of quarter
century old technical documents generated by way of the "marketplace" is
not the best evolution (not to imply anything radical and drastic).

honestly, i could do more productive work and play better games
on a 1KHz/1MB 1982 Apple than i can do today with a 1GHz/128MB Intel.
with the most advanced OS.  and i think the reason is due to the clarity
and accessibility OS intrinsics and development tools.  1978-1986 i spent
probably 5x more time programming than studying.  since 1986, I have spent
probably 100x more time studying than programming.  and it's been interesting,
but the end result is nothing except personal knowledge.  no creation.  and
i see it everywhere.  i see many people with good technical aptitude and
programming skills that wander into UNIX and either turn away or get bogged
down in the quicksand of trivial hacks and/or seemingly infinite study of
technical lineage and plethora of OS and library details.

> 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'.

ee and pico are notepad(tm) type junk.

> > 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.

yes, i meant "filesystem browser/manager" of course.

> 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?

as opposed to "cd"ing and "ls"ing around using cp/rm/mv/more/xv/xpdf/mpg123,
etc?  because it is often simpler and more effective to have 2 scroll-able
windows on a split screen that can be navigated with only arrow/tab keys
and "enter" when performing such functions.

> > 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.

heh :)  this is very interesting, since it concisely exposes what i tried to
put forth.  not tired, it's just not logical or reasonable.  sentences begin
after blank lines, 2 blank spaces, and/or periods.  to require additional
"layers" and special actions/functions and special keys/libraries to denote
the beginning of a sentence superfluous.  though i still see it's historical
merit in formal writing which had it's origins in handwriting where one may
have confused a "," and a "." at one time, thus justifying the additional
emphasis of a capital letter to denote the beginning of a sentence.  and i can
see "artistic" merit in that it may please some eyes more.  but i don't find
technical/functional merit to it in non-formal electronic writing, and it
pleases my eyes more to see only [a-z] as opposed to [A-Za-z].

> > 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.

i don't want instant messaging.  i don't have it, wouldn't want it,
and wouldn't use it.  ntalk/ytalk stuff is nice because, for one, it allows
shared display on the system where things on the system may be shared and
shown, and two, it has more of a "visiting" atmosphere than as opposed to
a "connecting" atmosphere.

> > 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

yes, this is my point.  it's just obfuscation.  i am sure there
are 100 ways to do things.  i am sure i can grab this package and
that package and over time do what i want.  but it's all hindering
the accomplishment of the goal.  if terminal drivers adopted a
fully functional set of ANSI escape sequences, i would need no
additional package.  and using reasonable logic, i shouldn't need
any additional packages.  furthermore, since all scripts/languages
contain "putchar/printf" or similar, i could do whatever term I/O
i wanted in any language with essentially the same libraries.

> >     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.

my point is vt/pcvt/xterm ANSI left/right scrolling capabilities are totally
lacking.  a reply stating that a 1/2 megabyte library will work around those
deficiencies is not a good solution IMHO.  a good argument would be to
demonstrate why a fully functional ANSI escape sequence set should not be
implemented in open source OS terminal drivers.  or why such a thing could
never be standardized.

> 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

i didn't claim that necessarily.  i simply claim that given a fully
functional set of ANSI escape sequences in the terminal driver, i do
not need ncurses/automake/configure/libtool/pkgconfig, etc.
and i claim that my code will be 10x smaller and much more CPU efficient.

> > 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.

well - that has not been made clear.  if ncurses does not use ANSI
escape sequences to control remote terminal drivers (which would be
definitely and grossly inefficient in some cases), then how is it
overcoming such deficiencies???  if the answer is "read the source",
forget it!

> 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

well i am thankful for your reply, and the effort to impart knowledge.
but i don't feel like my point was addressed.  i get the feeling like
terminal stuff is considered passe, and that further development in
terminal I/O is considered wasted effort.  and i guess that's a matter
of opinion, one i don't share.  i dislike bitmapped terminals except
where they are required (gtk type stuff).  i hate reaching for and
using mice whenever i can help it (i like kicking back with a keyboard
on my lap), i dislike menu navigation, and i dislike the contrast
(ie, i find it harder on the eyes to view graphic displays over time).

Chris