mcdonald@uxe.cso.uiuc.edu (07/06/88)
I just have to say something about the vi vs. good editors debate. Vi is an ergonomic disaster area. Its basic problem is that it is modal, very badly so. (I am NOT considering the possibility of any customization- beacuse the context is that a person learning it can instantly use it on ANY system with it, without having someone else customize it. If they learn it well enough they can of course do customizing.) You just can't learn a few commands and expect to be really useful, because you will accidentally hit an unlearned key and get sucked off into never-never land. One important goal of designing a user interface for an editor should be that a single key or set of keys does one and only one thing. It shouldn't matter what "mode" one is in. This is seldom totally feasible, but at a minimum one should have a normal mode wherein ALL the normal printing keys inset themselves in the text, where all cursor keys work, where destructive forward and backward delete work, etc. Preferably it should also do delete by words and lines, undelete by whatever it deletes, page up and page down. Vi doesn't do this. Emacs does, and so do virtually every other editor I have used - EDT for the VAX, Wordstar, Wordperfect, and many others for the IBMPC. Now all the ones I mentioned do have a "command mode", emacs less so than the others, but is is seldom necessary to use it. If one sees a mistake nearby in the text, you can just hit a couple of cursor keys, go there and fix things, and come back, without changing modes. Vi doesn't seem to do that. I feel it would be better to teach a better editor than vi. Emacs is certainly complicated, and might not be the answer, but there HAS to be something better than vi.
rick@pcrat.UUCP (Rick Richardson) (07/07/88)
I first used "vi" (3 months), then "emacs" (for 1 year), and then I went back to "vi" (now 8 years). The choice between these two editors depends upon two things: How long is your left pinky? How long is your short term memory? If you have very short pinkies, then you'll be happier with (moded) vi. If you have a short memory, then you'll be happier with (modeless) emacs. If you have both problems, then you should immediately choose another field. I have short pinkies. Luckily, despite rumors to the contrary, pinky length is not related to any other anatomical feature. :-) :-) :-) :-) -- Rick Richardson, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 389-8963 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
gallen@apollo.uucp (Gary Allen) (07/08/88)
In article <47800011@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >I just have to say something about the vi vs. good editors debate. >Vi is an ergonomic disaster area. Its basic problem is that it is modal, [...Mucho deleto...] >seem to do that. I feel it would be better to teach a better editor than >vi. Emacs is certainly complicated, and might not be the answer, but >there HAS to be something better than vi. This about sums it up for me. I dislike both (although vi a bit more) because of the amount of stuff that has to be remembered. I expect an editor to do just a couple of things, move left, right, up, down, and insert a character. Above that I really don't care. I really hate all the shift-hyper-meta-super- cali-ctrl-fragilistic of emacs, although it's generally unnecessary until I hit the wrong ctrl-character and wind up in hyper-space. I guess my favorite so far has been EDT but that generally requires VMS (The last place had a reasonable facsimile on UNIX) for which I have even less use. A good rule of thumb that I use in weighing editors is just to weigh the documentation (but then, I guess vi would win, huh? :-)). Anything that won't fit on a 3x5 card represents the over-active imagination of its author. Gary Allen Apollo Computer Chelmsford, Ma {decvax,yale,umix}!apollo!gallen
terryl@tekcrl.CRL.TEK.COM (07/09/88)
In article <3d1d2b9f.d8e9@apollo.uucp> gallen@diskless.UUCP (Gary Allen) writes: >I guess my favorite >so far has been EDT but that generally requires VMS (The last place had a >reasonable facsimile on UNIX) for which I have even less use. OHHHH, YYYUUUCCCKKKK!!! I was going to stay out of this discussion, editors being one of the things you never talk about (like religion & politics) because all of the discussions have the same fervored(sp?) pitch of one of those tele-evangelists, but I couldn't let the comment about EDT go by with- out voicing my disapproval. ***NOTE*** I used EDT on a VMS 1.6 system (i.e. MANY, MANY moons ago), so what I say may not be true now, but it certainly was back then. What was the worse thing about EDT I remember??? Well, it was a line- oriented editor, and to do a simple substitution one typed: s<ESC>pattern<ESC>new-pattern<CR> where <ESC> is what you think (i.e. 033 ASCII), pattern was the pattern you wanted to change, and new-pattern was what you wanted it changed to. Now, it wasn't the idea of using <ESC> as a separator (actually, I kinda like the idea of using a non-printable character as the separator), but the fact that once you typed the <ESC>, you were committed to filling out the rest of the line. What's even worse, you couldn't back up (i.e. erase) the <ESC>. Wait, there was something even worse than that; if EDT couldn't find the pattern on the current line, it would search from the current line till the end of file looking for pattern, and would change pattern to new-pattern if found. So, once you typed the second <ESC>, unless you were VEWWY, VEWWY careful (said in my best Elmer Fudd voice), you could be very, very up the proverbial creek without a paddle. EDT definitely violated the principle of least sur- prise. The second worse thing I remember about EDT was that once you were in it, ALL lines were numbered, and there was no way to defeat this FEATURE. When you inserted lines, what it would do is take the line numbers of the lines you were inserting between and AVERAGE them, and then start numbering the new lines with this average, with an increment of some choosing(fortunately there were ways to tell EDT what increment to use). Now, the side effect of this scheme is that sooner or later, you'll add enough lines to hit the number of the line your inserting before, and then EDT will drop you back into command mode automatically. If you're lucky enough, you'll just have to go into insert mode again and start adding lines, but sooner or later you won't be able to do that (the reason is that the line numbers of the two lines you want to insert between will have consecutive numbers). Once this happens, you have to re-number ALL of the lines in the file (there was no capability to re-number parts of the file). Gads, how I hated EDT!!!
peter@ficc.UUCP (Peter da Silva) (07/09/88)
There does not exist a decent editor on UNIX, or for that matter any other
system I have ever used.
A full GNU Emacs certainly has the power, but the brain-dead command set
(unless you customise the hell out of it) and the overloading of
non-printable characters is a royal pain... particularly since no two Emacs
implementations match. The way Emacs redraws the screen is a total disgrace,
too.
VI has a decent command set (though it'd be better if the range commands
were prefix instead of postfix, so they could provide feedback), but the
modefulness is mildly irritating (however understandable it might be)
and the relentless line-orientation gives me the screaming meemies. The
macros are brain-dead, too, but the regular expression capabilities almost
makes up for it.
It shouldn't be too difficult to allow for one bit of out-of-band
information. I.E., use the parity bit to indicate "command" and tie
it to an ALT key... if the channel doesn't carry it, then map it into
ESCAPE like Emacs does: but don't have any non-altmode commands.
If possible, hide this in the terminal.
The ^U convention for counts in Emacs is nice, but it'd be cleaner
to cons up counts out of ALT-0 through ALT-9. Search commands should
be (as in VI) actually part of the range-specifier (search with alt-/).
This would cut the number of commands down considerably.
I guess it'd be possible to set up a VI-mode like this in EMACS. Has
anyone done something like this? This, plus scrolling windows, would
completely convert me to Emacs. Right now I put up with VI.
--
-- `-_-' Peter (have you hugged your wolf today) da Silva.
-- U Ferranti International Controls Corporation.
-- Phone: 713-274-5180. CI$: 70216,1076. ICBM: 29 37 N / 95 36 W.
-- UUCP: {uunet,academ!uhnix1,bellcore!tness1}!sugar!ficc!peter.melnik@topaz.rutgers.edu (Ofer Melnik) (07/09/88)
I HATE EMACS! sorry to waste net space, but I just had to let it out. :-) I much prefer VI, but it's certainly not near perfect. My all time favorite program is WordStar. It does a good job of editing documents or programs... Too bad theres no WordStar for Unix :-) -Ofer [----------------------------------------+----------------------------------] [Ofer Melnik -- Rutgers University ! "If its not in the computer, ] [ melnik@topaz.rutgers.edu ! it doesn't exist." ] [----------------------------------------+----------------------------------]
chpf127@ut-emx.UUCP (J. Eaton) (07/09/88)
In article <2819@tekcrl.CRL.TEK.COM>, terryl@tekcrl.CRL.TEK.COM writes: > In article <3d1d2b9f.d8e9@apollo.uucp> (Gary Allen) writes: > >I guess my favorite > >so far has been EDT but that generally requires VMS > ..., but I couldn't let the comment about EDT go by with- > out voicing my disapproval. > > ***NOTE*** > > I used EDT on a VMS 1.6 system (i.e. MANY, MANY moons ago), so what I > say may not be true now, but it certainly was back then. > What was the worse thing about EDT I remember??? Well, it was a line- > oriented editor, Not true anymore, though it does have a line oriented mode, which I rarely use. Actually, vi is the most line oriented full screen editor I have ever used -- I can't make the cursor backup or move forward over the end of a line. Seems like an obvious thing to want to do, no? J. Eaton UT Department of Chemical Engineering Wasting time with news, and using vi.
cik@l.cc.purdue.edu (Herman Rubin) (07/09/88)
In article <2819@tekcrl.CRL.TEK.COM>, terryl@tekcrl.CRL.TEK.COM writes: > In article <3d1d2b9f.d8e9@apollo.uucp> gallen@diskless.UUCP (Gary Allen) writes: > >I guess my favorite > >so far has been EDT but that generally requires VMS (The last place had a > >reasonable facsimile on UNIX) for which I have even less use. ........... > The second worse thing I remember about EDT was that once you were in > it, ALL lines were numbered, and there was no way to defeat this FEATURE. > When you inserted lines, what it would do is take the line numbers of the > lines you were inserting between and AVERAGE them, and then start numbering > the new lines with this average, with an increment of some choosing(fortunately < there were ways to tell EDT what increment to use). Now, the side effect of < this scheme is that sooner or later, you'll add enough lines to hit the number < of the line your inserting before, and then EDT will drop you back into < command mode automatically. If you're lucky enough, you'll just have to go < into insert mode again and start adding lines, but sooner or later you won't < be able to do that (the reason is that the line numbers of the two lines you < want to insert between will have consecutive numbers). Once this happens, < you have to re-number ALL of the lines in the file (there was no capability < to re-number parts of the file). Gads, how I hated EDT!!! I wish I could have some such feature on the editors available. I find it extremely annoying to have line numbers changed in the editing process. With both vi and emacs, it is still true that all lines are numbered, but the numbers are constantly changing. Every insertion or deletion of a line now renumbers the entire file; is this any better than sometimes having to do so yourself? -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/11/88)
In article <1045@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >There does not exist a decent editor on UNIX, or for that matter any other >system I have ever used. [followed by a very incomplete description of his ideas for an editor] "There does not exist" requires either proof or exhaustive investigation. Just because neither "vi" nor "EMACS" strikes you as decent does not mean that some other editor might not. Have you tried the Grand editor (current incarnation of the RAND editor)? How about Sam, the most "decent" editor I've ever used?
sommers@njin.rutgers.edu (Mamaliz @ The Soup Kitchen) (07/11/88)
You're going to have to do some customization, no matter what; it sounds like you don't mind that but would rather avoid redesigning the entire command key mapping. There are vi emulators for every programmable Emacs, but they do emulate vi, so the command set is just as bad (or good). The most complete I've seen is viplus from UniPress, but it's just plain old Emacs underneath; you better not expect to use it the same way you use vi (edit, exit the editor, compile, edit, etc.). It's best to start it and stay in it. If you don't want to work that way, you'll hate it, but if you take the time to get used to it, you spend much less time thrashing. In most Emaces I've seen, ESC-0 through ESC-9 already do build the prefix argument. What don't you like about the way Emacs updates the screen (which Emacs, btw)? Some are better than others. Sometimes you have to tweak the termcap entry for Emacs to work well. liz sommers@njin.rutgers.edu
jlh@loral.UUCP (The Mad Merkin Hunter) (07/12/88)
In article <1045@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >There does not exist a decent editor on UNIX, or for that matter any other >system I have ever used. I have to agree with this. In order for an editor to be any good it has to be able to put the characters into my file without any intervention from me. This will give it a grade of 'C'. For a 'B' grade it has to do what I want it to do, not what I tell it. The only decent editor I've ever used was in grade school, in a 'home' environment running the 'family' OS. There I used 'mother' as an editor with very few complaints. Jim -- Jim Harkins Loral Instrumentation, San Diego {ucbvax, ittvax!dcdwest, akgua, decvax, ihnp4}!ucsd!sdcc6!loral!jlh
haugj@pigs.UUCP (Joe Bob Willie) (07/13/88)
In article <8235@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1045@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >>There does not exist a decent editor on UNIX, or for that matter any other >>system I have ever used. > >Have you tried the Grand editor (current incarnation of the RAND >editor)? How about Sam, the most "decent" editor I've ever used? the most decent editor i've ever used is "vi". and i keep around a set of turing machine macros just in case an editor flame war breaks out. ;-) - john. -- John "Evil USENET User" F. Haugh II HECI Exploration Co, Inc., Dallas UUCP: ...!killer!rpp386!jfh jfh@rpp386.UUCP :DOMAIN **** Trivia question of the day: VYARZERZIMANIMORORSEZASSEZANSERAREORSES? **** "You are in a twisty little maze of UUCP connections, all alike" -- fortune
ddb@ns.ns.com (David Dyer-Bennet) (07/13/88)
In article <1045@ficc.UUCP>, peter@ficc.UUCP (Peter da Silva) writes: > ...and the overloading of > non-printable characters is a royal pain [in emacs]... Depends what you edit. I insert non-printing characters other than space and return often enough to remember how to quote, and use it several times a month. > ...but the regular expression capabilities almost > makes up for it. [in vi] VI regular expressions are essentially identical to Gnu emacs or Epsilon regular expressions, near as I can tell. > The ^U convention for counts in Emacs is nice, but it'd be cleaner > to cons up counts out of ALT-0 through ALT-9. The Emacs I've used do this. Also Alt--, don't forget negative args. > Search commands should > be (as in VI) actually part of the range-specifier (search with alt-/). I find it easier to define a range by actually going to the limits of it, so I can be sure they're where I thought they were. Then having defined a region, it's easy to apply a command to a range. I don't like the way VI does it, it's too dangerous. Besides, most searches are for things I want to look at, not things I want to do something too. -- -- David Dyer-Bennet ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@viper.Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300
woods@gpu.utcs.toronto.edu (Greg Woods) (07/13/88)
In article <8235@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1045@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >>There does not exist a decent editor on UNIX, or for that matter any other >>system I have ever used. >[followed by a very incomplete description of his ideas for an editor] > >"There does not exist" requires either proof or exhaustive investigation. >Just because neither "vi" nor "EMACS" strikes you as decent does not >mean that some other editor might not. I whole-heartedly agree. We had a thing called fred at UofCalgary: the FRiendly EDitor, based on ed, with lots of features, including a "vi-like" full-screen mode. That's what I learned. Moved to Gosling emacs as soon as I could. But then I was a lisp fan. >In article <1559@edison.GE.COM> rja@edison.GE.COM (rja) writes: >>Here at work we have one version of emacs (ie; microEMACS) running on our > >And it would be great if each of the vendors mentioned supported that >particular delicious flavor of an admittedly great, editor microEMACS. WHY microEMACS? (FLAME ON!) I don't know how many of the features these people use, but I crashed my PC and dumped core on Xenix with microEMACS (my own incarnation from 3.7 with zillions of bug fixes already done) so many times, I gave up and used vi until Jove came along. Both the latest version of microEMACS (3.9i) and microGnuEmacs (latest posting) still contain many of the bugs I fixed (I know, I checked). If you've ever ported microEMACS, you'll swear at it until you're blue. It is the poorest piece of code I've ever worked on [;-)], I did most of my bug fixes for the Conroy(?) version that came with MWC, carried them up to 3.7, and it looks like lots still need doing again. BTW: I won't give out my 3.7.x version, since Jove is much better. :-) On the other hand, Jove (ie 4.6.1.4 and up) is the BEST written editor I've ever studied (I've seen Unipress Emacs both recently, and many years ago when Gosling was still writing it (I didn't know any better back then either), and I've had a brief Encounter With GNU emacs). Jove is very portable, and getting better all the time. 4.8 hasn't dumped core since I fixed one bug, and the only annoying thing is the occasional dropping of a line from the display. Don't bother flaming me about this flame. I don't care if you think I KNOW good code when I read it or not. Jove also seems to have more features, that work nicer, than the micro*EMAC's. Jove does enough that I don't miss lisp. Someone mentioned macros: vi macros are weird; Jove macros can do almost anything; lisp can do anything. Whoa! It's time to stop this nonsense! -- Greg Woods. UUCP: utgpu!woods, utgpu!{cpcc, ontmoh, ontmoh!cpcc, tmsoft!cpcc}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu (07/13/88)
Having started editting on punched paper tape in the 1960's and
seeming to have learnt one new editor every year since then.....(*SCREAM*)
Ah - that's better.
OK. Seriously.
Some people have mentioned the necessity of learning about 'ed'. I concur
(1) it handles larger files on our system than the other editors
(2) it is a neat tool for daemonic processes to use to alter files
(3) it is an online introduction to regular expressions (sed,grep,awk..)
For the last three quarters I have let my Systems Programming class loose
to explore UNIX. Most have had experience of other systems (PC, micro, mini,
mainframe). Some have already used EMACS. None have met 'vi/ex/ed' prior
to the class. Their task is to boldly go where...(oops) is to teach themselves
how to use UNIX. They buy two "Nutshell" books - "learning the UNIX System"
and "Learning the Vi Editor". I give no lectures and only a few demos
in class but they have full access to both the BSD UNIX documentation
and some other cheat sheets, help files, introductions online.
They are also encouraged to A.S.K. (Allways Seek Knowledge) via the
Mail command eiother to myself or to a group of 'gurus'.
Their task is to use the system to mail 10 weekly reports to the lecturer
Each report includes a list of one command's plus, minus
and interesting points. I make it clear to the class that I don't grade them
down for having and expressing strong opinions - only on matters of fact.
I therefore have about 400 reports on UNIX commands. These are on tape
so if anyone really wants them I can sumarize and anonomize them - but
this will be a lot of work...
I observe the following patterns:
They all learnt to use 'vi' with NO training (!).
25% get trapped in 'vi' at least once, 10% twice, 1% 4 times and have to
be killed by a passing superuser.
Nobody has flamed as much as I can about 'vi' (yet).
Nobody has said enything about jove(the local EMACS thing), ed, ex...
My conclusion is that 'vi' is a feasible editor for students.
I use 6 or 7 different editors on 4 or 5 machines every day.
All the ones I know including the three or four I have designed and
implemented are pretty evil in one way or another and I have had it up to
here with memorizing yet more abitrary commands and control sequences.....
I, personally, never want to learn another editor in my life.
Dick Botting
PAAAAAR@CCS.CSUSCC.CALSTATE(doc-dick)
paaaaar@calstate.bitnet
PAAAAAR%CALSTATE.BITNET@{depends on the phase of the moon}.EDU
Dept Comp Sci., CSUSB, 5500 State Univ Pkway, San Bernardino CA 92407
Disclaimer: What with my brain, my fingers, this Mac, the PDP, the CSU CYBERS
Transmission errors, your machine, terminal eyes and brain..
I probably didn't think what you thought you just read any way!peter@ficc.UUCP (Peter da Silva) (07/13/88)
In article <8235@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <1045@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: > >There does not exist a decent editor on UNIX, or for that matter any other > >system I have ever used. > [followed by a very incomplete description of his ideas for an editor] Complete enough to implement it, if you're of a mind to. Think "VI with alt-keys instead of modes". > "There does not exist" requires either proof or exhaustive investigation. You're right. I hereby change that to "I have not found a decent editor on UNIX...". > Just because neither "vi" nor "EMACS" strikes you as decent does not > mean that some other editor might not. True. Haven't found it yet. Closest yet has been "Brief" on the IBM-PC after excessive quantities of hacking the macros. > Have you tried the Grand editor (current incarnation of the RAND > editor)? No, I tried the Rand editor in a couple of incarnations. Does it still draw boxes around all your windows? (:-<) > How about Sam, the most "decent" editor I've ever used? No, how does it work and how do you get it? -- -- `-_-' Peter (have you hugged your wolf today) da Silva. -- U Ferranti International Controls Corporation. -- Phone: 713-274-5180. CI$: 70216,1076. ICBM: 29 37 N / 95 36 W. -- UUCP: {uunet,academ!uhnix1,bellcore!tness1}!sugar!ficc!peter.
peter@ficc.UUCP (Peter da Silva) (07/13/88)
In article ... sommers@njin.rutgers.edu (Mamaliz @ The Soup Kitchen) writes: [ how to deal with Emacs long start up time ] > It's best to start it and stay in it. If you don't want to work that way, > you'll hate it... Sounds like it won't interact with "vnews" very well, then. > What don't you like about the way Emacs updates the screen... I have never seen an Emacs that bothers using insert and delete line. When you delete or insert lines, they all seem to redraw the part of the window below the cursor. When you cursor down past the end of the window, they all redraw the whole window about 10 lines up. This latter behaviour is particularly annoying BTW, and would drive me batty even if they used insert/ delete line to optimise it. Which Emacs? The one on the DEC-20, microEmacs, MG, and what I think was a Goslingoid Emacs on an Integrated Solutions Optimum-5. -- -- `-_-' Peter (have you hugged your wolf today) da Silva. -- U Ferranti International Controls Corporation. -- Phone: 713-274-5180. CI$: 70216,1076. ICBM: 29 37 N / 95 36 W. -- UUCP: {uunet,academ!uhnix1,bellcore!tness1}!sugar!ficc!peter.
rja@edison.GE.COM (rja) (07/14/88)
In article <1988Jul13.005656.6@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > > In article <8235@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >In article <1045@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: (stuff quoted by Greg deleted here) > >In article <1559@edison.GE.COM> rja@edison.GE.COM (rja) writes: > >>Here at work we have one version of emacs (ie; microEMACS) running on our > > > >And it would be great if each of the vendors mentioned supported that > >particular delicious flavor of an admittedly great, editor microEMACS. > > WHY microEMACS? (FLAME ON!) ( flames deleted here ) > Greg Woods. > > UUCP: utgpu!woods, utgpu!{cpcc, ontmoh, ontmoh!cpcc, tmsoft!cpcc}!woods > VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada Folks, If you look closely at the quoted material above, you will note that I did not make the extravagant claims about microEMACS which get flamed. I was quoted by the person who made the claims ( "> >>" versus "> >"). I wish Greg had simply omitted me entirely, but I accept that it probably was inadvertant to include me in a manner which implied they were my words. For the record, I do not claim that microEMACS is "the ultimate editor." It does do a lot of things fine and is available for lots of machines. Jove, etc. are fine also. Editors are religious issues so whatever works for you....
dhesi@bsu-cs.UUCP (Rahul Dhesi) (07/15/88)
In article <1045@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >There does not exist a decent editor on UNIX, or for that matter any other >system I have ever used. Amen to that. The problem is that the average keyboard does not easily allow out-of-band signalling. Hence the eternal three-way war between keypad users (hunt-and-peck typists), Emacs users (meta/coke bottle/shift/alt/control keys) and vi users (constant mode switching). My own solution to this has been to invent an editor that directly interprets your brain waves to know if what you are typing is text or a command. A slight scowl on your face creates the right type of brain wave and causes what you type to become a command; a slight smile causes text input. A beneficial side-effect is the exercise: at a furious rate of editing, it is possible to burn as many as 100 calories per hour through the facial muscles alone. However, a startling noise, or the sudden appearance of a loved one, can cause the user to unconsciously change facial expressions and unexpectedly enter the wrong mode. Therefore for the time being the editor is still experimental. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
ok@quintus.uucp (Richard A. O'Keefe) (07/15/88)
In article <16475@brl-adm.ARPA> PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu writes: >Some people have mentioned the necessity of learning about 'ed'. I concur > (1) it handles larger files on our system than the other editors > (2) it is a neat tool for daemonic processes to use to alter files > (3) it is an online introduction to regular expressions (sed,grep,awk..) Re point (3): isn't it wonderful how many UNIX tools use regular expressions: sh, csh, ed, sed, grep, egrep, awk, vi, ..., and it isn't _so_ helpful that no two of them have the _same_ regular expression syntax. Re point (1): eh? What system is that? On far too many UNIX systems I have been forced to use 'ex' instead of 'ed' because the version of 'ed' provided was still configured for PDP-11s. I had formed the perhaps erroneous impression that a lot of vendors didn't take ed seriously any more. (I'm talking about e.g. a machine with 8M of real memory where ed was configured with an sbrk limit of 64k.) I'm even used to VIle/EXecrable giving up on files that aren't all that big. Beware of VIle/EXecrable with long lines: it has a nasty habit of truncating the data as well as the display. Emacsen are generally a better bet. Re point (2): ed is really meant to be interactive (the V.3 version will even _prompt_ if you ask it nicely); for scripts and daemons you're probably better off with sed (which is close enough to ed to get you really confused when it's different).
weemba@garnet.berkeley.edu (Obnoxious Math Grad Student) (07/15/88)
In article <3418@bsu-cs.UUCP>, dhesi@bsu-cs (Rahul Dhesi) writes: >My own solution to this has been to invent an editor that directly >interprets your brain waves to know if what you are typing is text or a >command. Too complicated. What you need is some foot pedals, and maybe a steering wheel. Students can relate to that. Well, most of them can. Personally, I don't know how to drive. I'm waiting for when FSF comes out with a free automobile. ucbvax!garnet!weemba Matthew P Wiener/Brahms Gang/Berkeley CA 94720
thad@cup.portal.com (07/15/88)
TOPS-20 EMACS does line inserts and deletes on terminals that have that capability (such as Datamedia DM3052), and uses region scrolling on VT100-like terminals. The recent mg2a on my 3B1 does region scrolling for VT100-like terminals, and mg2a on the Amiga does (what appears to be) region scrolling on the console window.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/29/88)
In article <1073@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >> How about Sam, the most "decent" editor I've ever used? >No, how does it work and how do you get it? Described in SP&E V17 pp813-845 (Nov 87). Available primarily via the AT&T UNIX System ToolChest (in the "dmd-pgmg" package).