> [EMAIL PROTECTED] wrote: > [ ... ] > > the basis for this question was to determine if it was > > feasible to write a portable FBSD application and/or library > > without external dependencies. > > You can write portable ANSI-C code using the STDIO routines, without external > dependencies upon termcap, ncurses, or anything else but libc. > > > it is understood what "ncurses" and "SLang" are for - and initially ANSI > > escape sequences seemed to provide a way to break through the burdens and > > complications of ncurses and termcap entries. > > Which are? Precisely what are you trying to do? > > 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? > > -Chuck
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. 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), and i am not happy with the current selection of terminal based browsers (i understand mc(1) to be the only real choice). these are critical to me as they things i use probably more than anything else. and i am tired of crazy configuration files. so i started out preliminary designs of an ANSI based terminal I/O and rc configuration (key/display/macro bindings, etc) library. 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, specifically when using editors and other terminal programs (such as lynx) inside these terminal windows across serial connections, and i don't think they are efficient over slow (modem) serial connections where i do much of my work. 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. 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. 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. the learning curves are fairly steep and are a "deterrent" to many wannabe programmers that don't have time in life to attain guru status but nevertheless would otherwise make valuable contributions. c) i assume (with a degree of ignorance) they must be nightmares to maintain, and based on what i've read - there's long histories of bugginess other crazy stuff due to overbroad attempts at compatibility (like SLangs regex's for example). d) neither SLang nor ncurses are available to scripts as ANSI escape sequences are via simple echo/printf statements. 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. 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. 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. 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. 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? _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"