CHUQUI@MIT-MC (03/22/83)
From: Charles F. Von Rospach <CHUQUI @ MIT-MC> Has anyone out there implemented the output of the Rand Editor through the curses packages? I have been considering it, but after getting into the code, I have found it to be a non-trivial enterprise. Anyone out there familiar enough to give a few hints on some of the more dense sections of the code? c
guy (04/09/83)
If it's a sufficiently old version of the Rand Editor, my suggestion is
"forget it". It has to be one of the worst C programs I have ever seen,
with a 14-page loop with a bowl of linguine for a control structure, "goto"s
all over the place. The code to provide "terminal-independence" is a mess
too; I had to work quite a while on it before discovering that the problem
with it on a VT100 is the VT100's unusual autowrap mode.
Besides, who wants an editor that wastes disk space and programmer patience
by turning tabs into spaces? It throws away information; our "ev" editor
and "vi" both record the fact that you hit the TAB key while typing in text
by stuffing a TAB character into the text.
Guy Harris
RLG Corporation
{seismo,mcnc,we13}!rlgvax!guypn (04/09/83)
I was instantly turned off by the rand editor when I saw what it did to my tabs. The documentation seemed somewhat incomprehensible too, being oriented towards a NED user, which I wasn't.
jsq (04/11/83)
Vi has the same problem as Stars and most other WYSIWYG workstations: you are forced to deal with formatting characters like tabs rather than dealing with blocks of text in space. Try moving a rectangular area with vi. If your ev is the same as the one we have here, it immediately does a brk to some ungodly large number, no matter how much data space it really needs. Talk about wasteful! Recent versions of the Rand editor are (slightly) better inside.
ellis (04/12/83)
Turning tabs into spaces is a feature, not a bug.... Do you really
like it when you're inserting text into tab-infested whitespace
and you can't type where you want because there's no "there" there ?
...or when trailing characters jump spasmodically when you type
the character that pushes it to the brink of the next tabstop ?
When I enter text, whitespace is whitespace is whitespace, tabs are
just a fast way to enter spaces up to the next tabstop. The number
of (badly conceived) programs that distinguish tabs from spaces
is pitifully small. I'll use vi, I guess, in those cases.
On the other hand, why the Rand editor doesn't properly compress
my whitespace into tabs where possible is beyond my comprehension...guy (04/12/83)
Turning tabs into spaces is a feature, not a bug.... Do you really
like it when you're inserting text into tab-infested whitespace
and you can't type where you want because there's no "there" there ?
...or when trailing characters jump spasmodically when you type
the character that pushes it to the brink of the next tabstop ?
This does not happen on "vi" or our (or some other) word processors, because
you can't PUT the cursor in the middle of tab-"infested" whitespace. On
our other editor, you can *tell* the difference between tabs and spaces
because it uses the VT100 "centered dot" character to indicate tabs (on
other terminals, you may lose). I have *no* problem with characters to
the right jumping; in fact, it's rather reassuring (it tells me that there
are *still* tabs there) and even fun to watch. It also means that if you
align comments on tab boundaries, they *stay* aligned there regardless of what
you insert at the left margin.
This discussion should be moved to net.flame; any further comments I make will
get sent there.
Guy Harris
RLG Corporation
{seismo,mcnc,we13}!rlgvax!guymat (04/13/83)
(Flame on!)
``Turning tabs into spaces is a feature, not a bug....''
I suppose that this depends on you notion of what a tab is. If
you view a tab as a command to the editor to adjust your current
position by space--padding, well, yes, then it IS a feature. To me,
the tab is a character (HT, octal value 011, in ASCII) and I would
like the editor to be able to handle it as such. The fact that this
character has an effect on your output device should effect the way
the editor displays the character, not on the way it stores it. Would
you want you ``carriage return'' key to fill in enouch spaces to make your
terminal wrap around?
``Do you really like it when you're inserting text into tab-infested
whitespace and you can't type where you want because there's no "there"
there ?''
Well, I have no problem using vi ... typing a couple of extra spaces isn't
THAT hard. And since most of my tab usage is for either indentation or
for writing tables (of initialized structures) I find tabs a VERY good way
to quickly accomplish my ends. In fact, I would like a key that would
produce two or three of them!
``...or when trailing characters jump spasmodically when you type
the character that pushes it to the brink of the next tabstop ?''
Sounds like some tabs were used where tabs were not appropriate. In
editing tables, this is perfectly acceptable. But WHAT are you doing
stuffing tabs into the middle of text?
``On the other hand, why the Rand editor doesn't properly compress
my whitespace into tabs where possible is beyond my comprehension...''
Hmm, now I begin to understand why a program I received for maintanance
had ****ing tabs placed where there should have been spaces. Single
spaces in mid--text were replaced with tabs when the space lay on top of
a tabstop. Must have been some brain--damaged editor.
``When I enter text, whitespace is whitespace is whitespace, tabs are
just a fast way to enter spaces up to the next tabstop.''
Well, what you need is a key that will enter multiple spaces. Of course,
what you are looking for is an electronic emulator for a typewriter, with
its tabulating properties. I agree that this could be useful, but it is
not the standard usage of the HT character.
``The number of (badly conceived) programs that distinguish tabs
from spaces is pitifully small. I'll use vi, I guess, in those cases.''
As I have already indicated, tabs are exteremly valuable for a small
set of extremely common (>98% of my work) situations. True, both are
considered whitespace by MANY but not all programs ( eg SORT(I) and (CUT(I))
because in these programs it is useful for humans to organize the inputs
with tabs. This organization (program indentation, etc) is not important
to these programs, and so they ignore it.
In short, if you have a need for a tabulator on your keypad, whether
hardware or software, please feel free to invent it and use it. Please do
not complain that a DIFFERENT mechanism, which works quite well in its
current use, is not just exactly what you need.
(Flame off!)
Mark Terribile
(Duke of deNet)
-!hou5e!matknight (04/15/83)
"Of course, what you are looking for is an electronic emulator for a typewriter, with its tabulating properties. I agree that this could be useful, but it is not the standard usage of the HT character." --Mark Terribile Bingo. This typewriter-like-ness of the Rand editor makes it extremely popular with Humanities people--that is to say, users (remember them?). By and large, they don't care that the HT character isn't being used in a standard fashion; they want to know why the hell they can't put eight characters in that eight-space margin without some special command. We have people here clamoring for a UNIX complement to the micro-based Rand lookalike we give them. Not to say that I *like* the thing, y'understand; I can't stand using it, and don't like the tab/space waste, either, but there *is* a place for it amongst the non-programmers in Academia. Trying to speak from the middle of road, Steve Knight ihnp4!stolaf!knight
obrien@rand-unix@sri-unix.UUCP (08/04/83)
This message is empty.
guy@rlgvax.UUCP (Guy Harris) (08/04/83)
The original article that you are replying to was posted several MONTHS ago,
so I'm sure many out there were somewhat confused by this reply. However,
earlier versions of the Rand editor didn't turn spaces back into tabs, so
this pertains only to the later version.
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guykendall@wjh12.UUCP (Kendall) (08/05/83)
I have also heard that the Rand Editor is a mess inside. Nonetheless, confined
as I now am to vi, I still dream about the Rand Editor's magnificent external
simplicity.
Sam Kendall
Delft Consulting Corporation
{allegra,ihnp4}!wjh12!kendall
decvax!genrad!wjh12!kendallJPAYNE@BBNG.ARPA@sri-unix.UUCP (08/07/83)
Why are you confined to vi?
cottrell@nbs-vms.ARPA (02/05/85)
/* > Has anyone heard of the 'Rand' editor? I found it on a > Perkin-Elmer 3210 running under UNIX-7 (Bourne and C-shell). > Where did the Rand editor originate and who supports it? > Is it from Perkin-Elmer? It seems to be much more user-friendly > than vi. It seems to be a page editor which draws windows, > can display several files simultaneously, tells you at all > times what is going on, and many other neat things. > By the way, everyone on that system prefers the Rand editor > over vi, except for the systems administrator. And he insists > on pronouncing vi like 'vye' instead of 'vee-eye'. (His previous job > was with Control Data.) > Any comments? > > Bernd Riechelmann (Not affiliated with U.C. San Diego) > UUCP: ...!ucbvax!sdcsvax!sdcc12!wa371, ARPA: sdcsvax!sdcc12!wa371@nosc VI is much more capable than RE. The keys all have mnemonic names, d for delete, w for word, i for insert, etc. I don't know how the keystrokes for RE were developed. RE is simple to learn tho. VI is more complex & powerful, and sometimes confusing. VI includes macros, repeat the last cmd that changed the text, undo same, multiple delete/yank buffers & markers, regular expressions, & shell escapes. RE does multiple windows and cursor defined open/close which is nice. VI is pronounced `vee-eye' as noted in `An Introduction to Display Editing with Vi' by William Joy. Nuff said! */
mwm@ucbtopaz.CC.Berkeley.ARPA (02/09/85)
In article <8035@brl-tgr.ARPA> cottrell@nbs-vms.ARPA writes: >VI is much more capable than RE. The keys all have mnemonic names, >d for delete, w for word, i for insert, etc. h for left, j for up, k for down, l for RIGHT!?!?. Really mnemonic names, those. Almost as slick as zilch, which uses u for down. Being of the emacs religion, I won't mention the multitude of missing features that editors really need; I'll just pray that I never, ever have to use the rand editor if what you say about it is true. Sounds like it could actually be *worse* than scope. <mike
robert@gitpyr.UUCP (Robert Viduya) (02/10/85)
>< Posted from cottrell@nbs-vms.ARPA > VI is much more capable than RE. The keys all have mnemonic names, > d for delete, w for word, i for insert, etc. I don't know how the > keystrokes for RE were developed. RE is simple to learn tho. > VI is more complex & powerful, and sometimes confusing. VI includes > macros, repeat the last cmd that changed the text, undo same, multiple > delete/yank buffers & markers, regular expressions, & shell escapes. > RE does multiple windows and cursor defined open/close which is nice. > VI is pronounced `vee-eye' as noted in `An Introduction to Display > Editing with Vi' by William Joy. Nuff said! > */ I dunno about the Rand Editor, but vi is just about the most terminal independent screen editor I've ever used. Here at Tech, we've got a number of different terminals, ranging from a few ADM3As and Regent 25s up to Wyse 300s, IBM-PCs (with just about any terminal emulator), and CDC 721s. Vi works on every single one of them and you don't have to 'reprogram' your fingers everytime you change terminals just because different manufacturers like to put cursor-keys and screen-control keys in different places and different layouts. I've found vi to be almost crippling in that respect since all the other screen editors available are the half-duplex type that *have* to use the special keys on a terminal. I frequently get into one of those editors and start hitting the 'j' key and start wondering both why the cursor isn't moving down and what are all the 'j's doing showing up in my file. robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
rwl@uvacs.UUCP (Ray Lubinsky) (02/20/85)
> >VI is much more capable than RE. The keys all have mnemonic names, > >d for delete, w for word, i for insert, etc. > > h for left, j for up, k for down, l for RIGHT!?!?. Really mnemonic names, > those. Almost as slick as zilch, which uses u for down. Being of the emacs > religion, I won't mention the multitude of missing features that editors > really need; ... ------------------------------------------------------------------------------ To come to the defense of vi(1): here at my Institution of Higher Learning, the masses (those of us graduate students who don't have office space) must use Lear-Siegler adm3a terminals. On these, the h,j,k,l keys are labeled with the appropriate arrows -- so, mnemonic or not, it's obvious which key does what function. On the adm5 on my desk, h,j,k,l still represent the same motion keys, though the separate arrow keys are still bound to ^H,^J,^K,^L respectively. Any how, the h,j,k,l keys are conveniently placed under my fingers. That counts for a lot. We have Rand Editor here; it's about as popular as vi(1). I'm a proponent of the latter, but I _would_ like windowing. Someday I'll grok EMACS, but for now I can still accomplish a lot with vi(1). ------------------------------------------------------------------------------ Ray Lubinsky University of Virginia, Dept. of Computer Science uucp: decvax!mcnc!ncsu!uvacs!rwl
jsdy@hadron.UUCP (Joseph S. D. Yao) (03/02/85)
> Posted from cottrell@nbs-vms.ARPA > > VI is much more capable than RE. The keys all have mnemonic names, > > d for delete, w for word, i for insert, etc. I don't know how the > > keystrokes for RE were developed. RE is simple to learn tho. > > I dunno about the Rand Editor, but vi is just about the most terminal > independent screen editor I've ever used. ... Dave, if you're reading this, here's your religious issue again. Ever since somebody [;-)] introduced Dave Yost to Mark Horton at a USENIX meeting, the Rand Editor has been terminal-independent via the termcap file. The keystrokes were developed for the Ann Arbor K4080 terminal with S1901 Emulation Option -- tho nobody has ever been able to tell me what S1901 was. It was multi-window back when the Mac was just an Apple in somebody's I. It is great! for multiple- text applications (among other things, i used to use it as a "visual diff" -- can't do that in vi!) and for general dumb sit-and-enter-text type of applications. It allows all manner of filters to be run from it and is therefore extensible just as 'vi' is. Our secretaries at SAI (when I was at SAI) in Rosslyn (when...) in 1976-1980 were intro- duced to Re and Nroff (subset/macro pkg), and soon absolutely loved the whole system! Especially the trekkie who discovered startrek... Even the Management was occasionally found typing at the terminals! We had the AA-K4080 terminals, where you just hit the appropriate key to do anything you wanted. Entry was trivial, and all manner of editing tasks (cut&paste, retrieve your 2-hour-ago change) were easy. That was ~version 3? Today they are up to version 24+? I have been using vi for quite a while because (a) it is everywhere, and (b) I am writing C programs, and 'vi' has some nice features for C. I may get back to 'e' (new 're') for text, and learn Emacs for C. On this particular religious issue I am easy (I don't even use the Bourne- again Shell). But I do steadfastly maintain: Emacs and the Rand Editor are true screen editors. Vi and Vteco are, respectively, line and character editors playing screen editor. Try them and see. Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}