> 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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"