bob@imspw6.UUCP (Bob Burch) (03/07/89)
From Ted Holden, HTE: About the only good thing I can say about the vi editor, which I've been unsuccessfully trying to avoid for about the last ten years, is that it's a standard. AT&T should get together with Sammy Mitchell or somebody who knows how to construct reasonable modern text editors and come out with something up to 1989 standards for a text editor for V.4 and just get rid of vi which, along with nroff and troff and a couple of other items I could mention, cannot possibly be serving any further purpose other than as ammunition for the UNIX-haters. Ted Holden HTE
jik@athena.mit.edu (Jonathan I. Kamens) (03/07/89)
Must we get into the flame wars about different Unix(TM) text editors
again? I {\em really} don't think we're going to get any more out of
it this time than we have at any time in the past. I think they
keyword when it comes to editors is "tolerance" -- you like your
editor, other people like theirs, and it should stay that way.
In article <222@imspw6.UUCP> bob@imspw6.UUCP (Bob Burch) writes:
>From Ted Holden, HTE:
>
>[flames about vi, nroff and troff]
Jonathan Kamens USnail:
MIT Project Athena 410 Memorial Drive, No. 223F
jik@Athena.MIT.EDU Cambridge, MA 02139-4318
Office: 617-253-4261 Home: 617-225-8218richard@torch.UUCP (Richard Nuttall) (03/09/89)
>From Ted Holden, HTE: >About the only good thing I can say about the vi editor, which I've >been unsuccessfully trying to avoid for about the last ten years, is >that it's a standard. AT&T should get together with Sammy Mitchell or >somebody who knows how to construct reasonable modern text editors and >come out with something up to 1989 standards for a text editor for V.4 >and just get rid of vi which, along with nroff and troff and a couple >of other items I could mention, cannot possibly be serving any further >purpose other than as ammunition for the UNIX-haters. ABSOLUTELY!!!! I HATE vi. I have only had to use vi in the last couple of months, before that I have used decent custmisable editors (WYSIWYG) such as VAX TPU (a highly customised version of EVE) APOLLO dm editor MICROSOFT C5.1 M editor I am currently trying to find a sensible editor that I can use on Torch Quad-X, Torch XXX, Sun386, Sun3/60, Sun4, all running some form of unix or other, both native mode (i.e. suntools) and with xterm. I have tried JOVE and am looking at CRISP, but what I really want is one that, when running X, you can use the mouse to copy around text, point to a place in the text, and resize windows dynamically without blowing up the editor. I have heard that a GNU EMACS can do at least some of this, and am trying to get the sources at the moment. Does anyone have any other suggestions for customisable WYSIWYG editors that are portable and work with X ? (I know its asking a lot). -- Richard Nuttall | ukc!stc!datlog!torch!richard Torch Technology Ltd. | Cambridge England | 0223 841000 X 309
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (03/09/89)
In article <222@imspw6.UUCP> bob@imspw6.UUCP (Bob Burch) writes: | About the only good thing I can say about the vi editor, which I've | been unsuccessfully trying to avoid for about the last ten years, is | that it's a standard. AT&T should get together with Sammy Mitchell or | somebody who knows how to construct reasonable modern text editors and | come out with something up to 1989 standards for a text editor for V.4 | and just get rid of vi which, along with nroff and troff and a couple | of other items I could mention, cannot possibly be serving any further | purpose other than as ammunition for the UNIX-haters. (a) are you perhaps confusing text editors with word processors? (b) why don't you use emacs, or brief, or whatever without trying to shove your ideas down our throats. (c) nice to know vi and troff are obsolete. We run a number of machines which do nothing else. People make money selling vi and [nt]roff for MS-DOS. Could it be people *like* these tools? (d) you don't usually post as though God gave you special insight into the problems of the world, what in hell got into you this time? -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
miket@brspyr1.BRS.Com (Mike Trout) (03/10/89)
In article <9653@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > Must we get into the flame wars about different Unix(TM) text editors > again? I {\em really} don't think we're going to get any more out of > it this time than we have at any time in the past. I think they > keyword when it comes to editors is "tolerance" -- you like your > editor, other people like theirs, and it should stay that way. Well, that's true; everybody has a right to their own opinions and tastes, BUT: You can use vi all you want, and it may work just fine for you. Fine; that's your business. But you should be aware that while you are putt-putting along in your Sopwith Pup, most of the rest of us have climbed into P-38 Lightnings. You may be very comfortable with the Pup, but the real world has left you behind. The Pup may serve you very well the rest of your days, but God help you if you ever find yourself in serious financial competition with somebody who uses up-to-date text editors. In the 1970s, vi was the greatest thing since hot fudge sundaes. But check your calendars. The world moves on, and "it should stay that way" is an attitude that blows away with the wind every decade or so. I'm sure that this was the same argument used when transistors began to replace vacuum tubes: "I like tubes, I'm comfortable with them, and I'm going to continue to use them. It should stay that way." Guess what happened to all those vacuum tube freaks? -- NSA food: Iran sells Nicaraguan drugs to White House through CIA, SOD & NRO. ~~~~~~~~~~~~~~~~~~~~~~~~Michael Trout (miket@brspyr1)~~~~~~~~~~~~~~~~~~~~~~~~~ BRS Information Technologies, 1200 Rt. 7, Latham, N.Y. 12110 (518) 783-1161 "God forbid we should ever be 20 years without...a rebellion." Thomas Jefferson
bph@buengc.BU.EDU (Blair P. Houghton) (03/10/89)
In article <222@imspw6.UUCP> bob@imspw6.UUCP (Bob Burch) writes: > >From Ted Holden, HTE: > >About the only good thing I can say about the vi editor, which I've >been unsuccessfully trying to avoid for about the last ten years, is >that it's a standard. AT&T should get together with Sammy Mitchell or >somebody who knows how to construct reasonable modern text editors and >come out with something up to 1989 standards for a text editor for V.4 >and just get rid of vi which, along with nroff and troff and a couple >of other items I could mention, cannot possibly be serving any further >purpose other than as ammunition for the UNIX-haters. Tell Ted to put his cap-pistol away. Vi is a perfectly sound editor. --Blair "Whaddaya mean, I have to learn Lisp just to compose a macro...!?"
peter@ficc.uu.net (Peter da Silva) (03/10/89)
In article <5552@brspyr1.BRS.Com>, miket@brspyr1.BRS.Com (Mike Trout) writes: > You can use vi all you want, and it may work just fine for you. Fine; that's > your business. But you should be aware that while you are putt-putting along > in your Sopwith Pup, most of the rest of us have climbed into P-38 Lightnings. Balderdash. vi might be hard for some people to learn (though god knows why... it's the only editor I know of for UNIX with a consistant syntax), but it's got features I can't do without. I haven't found another editor, on any machine, that does a decent job of supporting regular expressions for search and replace... something I use continually. You like analogies? How about this one. You can use $(your-favorite-editor) all you want, and it might work just fine for you. Fine; that's your business. But you should be aware that while you're backing your Caddilac out of the driveway and coaxing it down the street, we've already been to the grocery and back. > you if you ever find yourself in serious financial competition with somebody > who uses up-to-date text editors. This is so weird I can't begin to address it. I'll just ask how much of programming is coding? Some of us even use pencils and paper when designing a system... > Guess what happened to all those vacuum tube freaks? They got good jobs at audiophile magazines? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
ked@garnet.berkeley.edu (Earl H. Kinmonth) (03/11/89)
In article <5552@brspyr1.BRS.Com> miket@brspyr1.BRS.Com (Mike Trout) writes: >In article <9653@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > >your business. But you should be aware that while you are putt-putting along >in your Sopwith Pup, most of the rest of us have climbed into P-38 Lightnings. How about something other than cute rhetoric? How do you measure performance and utility differences in editors? How did you make such measurements? Did you make such measurements? There is also more to editors than perceived speed. Here is a test for your favorite editor. Let me know if it passes. vi does, at least on Sony work stations. The test: can your editor process text and programs destined for all of the world's largest computer and software markets. (In case you've been too busy tooling around in your P38 to notice, Japan is the second largest market, and in 1992 it will be the EEC. That means your editor must handle all European languages plus Japanese.)
mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) (03/11/89)
In article <5552@brspyr1.BRS.Com> miket@brspyr1.BRS.Com (Mike Trout) writes: :In article <9653@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes: : :> Must we get into the flame wars about different Unix(TM) text editors :> again? I {\em really} don't think we're going to get any more out of :> it this time than we have at any time in the past. I think they :> keyword when it comes to editors is "tolerance" -- you like your :> editor, other people like theirs, and it should stay that way. : :Well, that's true; everybody has a right to their own opinions and tastes, BUT: : :You can use vi all you want, and it may work just fine for you. Fine; that's :your business. But you should be aware that while you are putt-putting along :in your Sopwith Pup, most of the rest of us have climbed into P-38 Lightnings. :You may be very comfortable with the Pup, but the real world has left you :behind. The Pup may serve you very well the rest of your days, but God help :you if you ever find yourself in serious financial competition with somebody :who uses up-to-date text editors. : :In the 1970s, vi was the greatest thing since hot fudge sundaes. But check :your calendars. The world moves on, and "it should stay that way" is an :attitude that blows away with the wind every decade or so. I'm sure that this :was the same argument used when transistors began to replace vacuum tubes: :"I like tubes, I'm comfortable with them, and I'm going to continue to use :them. It should stay that way." Guess what happened to all those vacuum tube :freaks? : :-- :NSA food: Iran sells Nicaraguan drugs to White House through CIA, SOD & NRO. :~~~~~~~~~~~~~~~~~~~~~~~~Michael Trout (miket@brspyr1)~~~~~~~~~~~~~~~~~~~~~~~~~ :BRS Information Technologies, 1200 Rt. 7, Latham, N.Y. 12110 (518) 783-1161 :"God forbid we should ever be 20 years without...a rebellion." Thomas Jefferson Sure, you could always use WordPerfect. Until they carry you kicking and screaming into the night. -- Dan Mercer Reply-To: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer)
walkerb@tramp.Colorado.EDU (Brian Walker) (03/11/89)
In article <3370@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >You can use $(your-favorite-editor) all you want, and it might work just >fine for you. Fine; that's your business. But you should be aware that >while you're backing your Caddilac out of the driveway and coaxing it down >the street, we've already been to the grocery and back. In article <5552@brspyr1.BRS.Com>, miket@brspyr1.BRS.Com (Mike Trout) writes: > You can use vi all you want, and it may work just fine for you. Fine; that's > your business. But you should be aware that while you are putt-putting along > in your Sopwith Pup, most of the rest of us have climbed into P-38 Lightnings. In article <666@The_Machine>, floyd@The_Machine.NET (Pink Floyd) Writes: > My editor is better than your editor, so go [explicative deleted] yourself. Actually, for all of it's clunks and clatters, vi is livable. I wouldn't mind having a true full screen editor, but vi does offer the ability to work on any terminal for which a termcap is defined. It's command set isn't as bad as the one for Emacs (as in, :wq is a lot easier to grasp than ^X^F). And, you can learn to hit the dreaded [esc] key. On VMS however, my preferred editor is EVE. It's a nice full screen editor that works like I expect full screen editors to work. On the down side, it needs VT-100 emulation or better so using EVE on the TVI-912 terminals around here is not. -- an option to consider seriously. Brian Walker, University of Colorado at Boulder walkerb@tramp.colorado.edu ...!{ncar,nbires}!boulder!tramp!walkerb A person who claims that absolute zero is impossible to obtain has not taken a quiz in thermo yet.
steiny@hpcupt1.HP.COM (Don Steiny) (03/11/89)
> From Ted Holden, HTE: > AT&T should . . . come out with . . . a text editor for > V.4 and just get rid of vi . . . Why don't you just write one? I am sure that since it would be such a big improvement you would make a bundle.
krazy@claris.com (Jeff Erickson) (03/11/89)
From an article by walkerb@tramp.Colorado.EDU (Brian Walker): > Actually, for all of it's clunks and clatters, vi is livable. I wouldn't mind > having a true full screen editor, but vi does offer the ability to work on any > terminal for which a termcap is defined. It's command set isn't as bad as the > one for Emacs (as in, :wq is a lot easier to grasp than ^X^F). And, you can > learn to hit the dreaded [esc] key. > With the version of emacs I grew up on, and with enough work, you could program it to act exactly like vi. That's on of the main advantages (I think) of emacs: I can customize it to my heart's delight. I can make any key do anything. If I don't like something, I can change it to something I do like. I don't know how many times I've wanted to do that with other text editors/word processors!! Having been spoiled by emacs, I really dislike vi. -- Jeff Erickson \ Internet: krazy@claris.com AppleLink: Erickson4 Claris Corporation \ UUCP: {ames,apple,portal,sun,voder}!claris!krazy 415/960-2693 \________________________________________________________ ____________________/ "I'm so heppy I'm mizzabil!"
c60c-3ds@web-1b.berkeley.edu (John Kawakami) (03/11/89)
For the record: I like both vi and emacs/JOVE/GNUemacs about the same. I like
them much more than "word processors" for most applications because most of
the text I deal with is code or unformatted text. If you do different types
of editing, you need different editors. That's that.
What would be nice to have is a small editor that can automatically format
source code the way you want it, and without lots of hassle (GNUemacs is
_not_ small!). It should also be able to do rudimentary real time syntax
checking, so a stray letters don't blow a compile. A larger buffer for the
line on the bottom of the screen could give me more information on matching
parens, errors, text marks, search strings. Maybe even better support for
better hilighting esp. on color monitors.
Another significant development will probably be natural language commands
that neophytes (read, non hacker/programmer/superuser) can use. Imagine,
someone doing a _real_ search without ever learning what a regexp is.
John Kawakami c60c-3ds@web.berkeley.edu bogstad@smoke.BRL.MIL (William Bogstad ) (03/11/89)
In article <252@torch.UUCP> richard@torch.UUCP (Richard Nuttall) writes: >ABSOLUTELY!!!! >I HATE vi. > >I have only had to use vi in the last couple of months, before that >I have used decent custmisable editors (WYSIWYG) such as > Just out of curiosity ,but what particular feature or non-feature of vi makes it not a WYSIWYG editor? With vi you get exactly what you see on your screen no more and no less. Bill Bogstad BTW, I don't use vi.
cosell@bbn.com (Bernie Cosell) (03/11/89)
In article <7324@boulder.Colorado.EDU> walkerb@tramp.Colorado.EDU (Brian Walker) writes: }Actually, for all of it's clunks and clatters, vi is livable. I wouldn't mind }having a true full screen editor, but vi does offer the ability to work on any }terminal for which a termcap is defined. It's command set isn't as bad as the }one for Emacs (as in, :wq is a lot easier to grasp than ^X^F). And, you can }learn to hit the dreaded [esc] key. Actually, you hardly have to hit "escape" at all in vi. a bit of creative use of the "map!" command and you can have essentially ALL of your normal-editing chars available in input-mode. Once you do that, it stops being "input mode versus command mode", but rather "text editing mode versus general command mode". You can't quite do *everything* you might like, but you can come *awful* close. [e.g., as I type this in input mode, my arrow keys are "enabled", I have word-forward/backward, end-of-line, beginning-of-line, a fistful of assorted deletes and some other junk all set up.] I actually like it BETTER that way: when I'm typing in running text, the *only* commands active are those that relate directly to typing-in-running-text. All the random ones (save the file, copy a paragraph, etc, etc) require that (in the way I look at things) I *do* something to "enable" all the other non-local commands. I could do lots more with my .exrc, but bascially I added input-mode-commands until I found that I didn't need any more and then I stopped (yes, the emacs philosophy of "you should do everything you can" isn't the preferred operating mode for some of us)... for example, I worked up a bunch of language-specific command sets, for TeX, and C and Lisp and... but mostly I didn't need them enough so I didn't bother finishing them up. About the only thing I really miss with vi is being about to point-at, and mark-regions-of text with my mouse. __ / ) Bernie Cosell /--< _ __ __ o _ BBN Sys & Tech, Cambridge, MA 02238 /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com
john@frog.UUCP (John Woods) (03/12/89)
In article <9837@smoke.BRL.MIL>, bogstad@smoke.BRL.MIL (William Bogstad ) writes: > In article <252@torch.UUCP> richard@torch.UUCP (Richard Nuttall) writes: > >ABSOLUTELY!!!! > >I HATE vi. > >I have only had to use vi in the last couple of months, before that > >I have used decent custmisable editors (WYSIWYG) such as > Just out of curiosity ,but what particular feature or non-feature > of vi makes it not a WYSIWYG editor? With vi you get exactly what you > see on your screen no more and no less. > Ah, but wimps who would say "wishywig" with a straight face would never be content with monopitch, monofont, ragged-edge printed documents, no matter how unimportant the actual text is... :-) -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu "He should be put in stocks in Lafeyette Square across from the White House and pelted with dead cats." - George F. Will
dieter@jupiter.nmt.edu (The Demented Teddy Bear) (03/12/89)
In article <9837@smoke.BRL.MIL>, bogstad@smoke (William Bogstad ) writes: > Just out of curiosity ,but what particular feature or non-feature > of vi makes it not a WYSIWYG editor? With vi you get exactly what you > see on your screen no more and no less. Well, one of my favorite examples is editing executables (yes, I know this is evil and vile, but when you don't have source and a hard-wired string is completely wrong....) You can do this under GNU (and probably other) Emacs. Vi complains about non-ASCII characters and truncated lines, and when you write the resulting file out, you get an exec error (bad format, I believe). Also, the screen display is missing the top few lines (why, I don't know, but it's consistent behaviour). This, BTW, is on a Sun 3 running SunOS 3.5. I've used Emacs to edit binaries on several flavors of Unix, so it isn't specific to Sun. The other major lack is windowing. Being able to actually see multiple files (or non-adjacent parts of the same file) is incredibly helpful. Overall, though, Emacs is not a WYSIWIG editor. That usually implies that you see italics, bold face, and what not exactly as it will appear in the resulting print-out. For (hopefully) obvious reasons, this isn't practical in the Unix world. Sure, you may have a bit-mapped display on your desk, but the five blokes down the hall rlogin'd from their VT-100s don't have quite the same resolution. But, being able to see everything in the file helps. Dieter -- Welcome to the island. You are number six. dieter%nmt@relay.cs.net dieter@jupiter.nmt.edu
bph@buengc.BU.EDU (Blair P. Houghton) (03/12/89)
In article <252@torch.UUCP> richard@torch.UUCP (Richard Nuttall) writes: > >Does anyone have any other suggestions for customisable WYSIWYG editors >that are portable and work with X ? (I know its asking a lot). You could try Xedit, but then it's YOUR computer... --Blair "...and _you_ have to clean up after it and keep it fed and..."
bph@buengc.BU.EDU (Blair P. Houghton) (03/12/89)
In article <9059@claris.com> krazy@claris.com (Jeff Erickson) writes: >From an article by walkerb@tramp.Colorado.EDU (Brian Walker): >>Actually, for all of it's clunks and clatters, vi is livable. I >>wouldn't mind having a true full screen editor, but vi does offer the >>ability to work on any terminal for which a termcap is defined. It's >>command set isn't as bad as the one for Emacs (as in, :wq is a lot >>easier to grasp than ^X^F). And, you can learn to hit the dreaded >>[esc] key. >With the version of emacs I grew up on, and with enough work, you could >program it to act exactly like vi. > >That's on of the main advantages (I think) of emacs: I can customize it >to my heart's delight. I can make any key do anything. [...] That's one of vi's even bigger advantages; while it, too can be re-macroed to do whatever you please, there ain't no way you're going to ever put together the macros to make it act like emacs :-) :-) :-) --Blair "And if you ever wanted to, I'd sell you forty percent of my thirty percent of the consortium's tewnty percent of the Brooklyn bridge. |-D |-D |-D |-D |-D |-D |-D
nmm@apss.ab.ca (Neil McCulloch) (03/12/89)
In article <252@torch.UUCP>, richard@torch.UUCP (Richard Nuttall) writes: > ABSOLUTELY!!!! > I HATE vi. > > I have only had to use vi in the last couple of months, before that > I have used decent custmisable editors (WYSIWYG) such as At the risk of contributing to editor wars... Look, vi might not do all you want it to do, and YOU might find it hard to use. However, you can teach a complete neophyte how to use vi in about 5 minutes, and it is powerful and customisable enough to meet your average user's needs. There are lots of editors out there, each one the best for a particular situation. It is up to the user to choose the tool required to do the job they want to do. This is part of the UNIX philosophy. Hence UNIX gives us: sed, ed, ex, vi as standard. To which you can add you're favourite emacs clone or other editor. Incidentally, the same goes for other UNIX tools: nroff, troff and so on. Each one does a particular job at a certain level of complexity. People who criticise UNIX for having this hierachal approach to tool and application programs simply miss the point. And finally, there are top of the line applications programs becoming available to meet the needs of users with very specific needs and dare I say it, predilections. Cheers, neil Header says it all...
karish@forel.stanford.edu (Chuck Karish) (03/13/89)
In article <1028@apss.apss.ab.ca> nmm@apss.ab.ca (Neil McCulloch) wrote: >In article <252@torch.UUCP>, richard@torch.UUCP (Richard Nuttall) writes: >> ABSOLUTELY!!!! >> I HATE vi. >> I have only had to use vi in the last couple of months, before that >> I have used decent custmisable editors (WYSIWYG) such as >Look, vi might not do all you want it to do, and YOU might find it hard >to use. However, you can teach a complete neophyte how to use vi in >about 5 minutes, and it is powerful and customisable enough to meet >your average user's needs. vi is fine as a programmer's editor, where the writer has to control all the line breaks anyway. I use it all day long. It's not as good as a general-purpose text editor. Try to teach a secretary vi AND troff in five minutes. WordPerfect is available for some Unix systems. Chuck Karish karish@denali.stanford.edu hplabs!hpda!mindcrf!karish (415) 493-7277
prc@maxim.ERBE.SE (Robert Claeson) (03/13/89)
In article <7324@boulder.Colorado.EDU>, walkerb@tramp.Colorado.EDU (Brian Walker) writes: > On VMS however, my preferred editor is EVE. It's a nice full screen editor > that works like I expect full screen editors to work. On the down side, it > needs VT-100 emulation or better so using EVE on the TVI-912 terminals around > here is not. EVE on a VT220-or-better terminal is probably the best editor I've ever used. Anyone who knows of a PD version of TPU and EVE for UNIX? 8> -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20 EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SE
gaynor@athos.rutgers.edu (Silver) (03/13/89)
john@frog.UUCP writes: > Ah, but wimps who would say "wishywig" with a straight face would never be > content with monopitch, monofont, ragged-edge printed documents, no matter > how unimportant the actual text is... :-) This brings to mind several readability issues which it won't hurt to air again. In general, - Text written in ALL UPPER-CASE (of the same font as the surrounding text) is *much* harder to physically read. The reason for this is that the upper-case characters in a given font are basically the same size, and, in most fonts, don't extend below the base line at all (except Q on occasion). (Mixed-font upper case is usually ok, e.g., LaTeX's \sc declaration.) - Unless the space between characters and words can be adjusted uniformly, text that is both left- and RIGHT-JUSTIFIED is difficult to read. The non-uniform gaps tend to catch the eye and keep it there. Much better to leave the right edge ragged. - DOUBLE-SPACED text is slightly more difficult to read than text less-heavily spaced. Text too closely spaced can also be difficult. (If you're using LaTeX, try a stretch of 1.2 - 1.3 with the default skip, and see if you like that better.) - LONG AND SHORT LINES (outside of something like [20, 80]) are more difficult to read. For the real long lines, the eye has trouble spotting the beginning of the next line. For read short lines, the eye has to shift to the beginning of the next line too often. I'm told that 50 - 60 characters is optimum. (You can see that I choose to trade optimal line length for better usage of screen acreage). Comments? Additions? Regards, [Ag] gaynor@rutgers.edu "vi's a dog!"
ath@helios.prosys.se (Anders Thulin) (03/13/89)
In article <Mar.12.17.20.24.1989.29073@athos.rutgers.edu> gaynor@athos.rutgers.edu (Silver) writes: > In general, > [ ... ] > - Unless the space between characters and words can be adjusted uniformly, > text that is both left- and RIGHT-JUSTIFIED is difficult to read. The > non-uniform gaps tend to catch the eye and keep it there. Much better to > leave the right edge ragged. I would like to restrict that to adjusting space between words only. Most readers don't read the letters of a word, they read the entire word in one 'gulp'. Adjusting the space between the letters changes the 'image' of the word, and makes it more difficult to read. [Caveat lector: This is only my opinion. I don't know of any legibility research that contradicts it. Do you? If you do, I'd like to know of it.] Also, altering the letter spacing inside words usually changes the 'colour' of the page, and gives 'grey' spots or bands on the page. This might be unwanted in very high-quality printing. -- Anders Thulin INET : ath@prosys.se ProgramSystem AB UUCP : ...!{uunet,mcvax}!enea!prosys!ath Teknikringen 2A PHONE: +46 (0)13 21 40 40 S-583 30 Linkoping, Sweden FAX : +46 (0)13 21 36 35
rowland@hpavla.HP.COM (Fred Rowland) (03/13/89)
OK, Mike Trout, you believe that vi, troff, nroff and their kin are obsolete. I'm inclined to agree with you, except for vi. But please enlighten us: What should we be using? What meets with your approval? What measures up to the 80's? What do we do next year when the 80's become obsolete? What will those in the know be using in the 90's? What was the point of your note? Fred Rowland
gregg@ihlpb.ATT.COM (Wonderly) (03/13/89)
From article <9059@claris.com>, by krazy@claris.com (Jeff Erickson): > > That's on of the main advantages (I think) of emacs: I can customize it > to my heart's delight. I can make any key do anything. If I don't like > something, I can change it to something I do like. I don't know how many > times I've wanted to do that with other text editors/word processors!! > > Having been spoiled by emacs, I really dislike vi. And what happens when you sit down to help somebody with something and they don't have *macs set up the way you do? Can you shift gears and learn their brand of mappings in short order? If so, you could probably learn vi or the standard mappings for *macs as well instead of working yourself into a state of dependence on something that is so incompatible with other environments. Seriously, I thought it was common knowledge that right or wrong standard ways and methods yield common knowledge and higher productivity! That is precisely why you won't see me using zillions of aliases and shell scripts. I have a few, but just enough to get by, like alias ls="ls -CF". If a tool doesn't do the right thing to begin with, I find it hard to believe that the tool is worthy of being called a tool! The 'right thing' is hard to define, but certainly the fact that so many people change and add mappings to *macs says something! -- Gregg Wonderly DOMAIN: gregg@ihlpb.att.com AT&T Bell Laboratories UUCP: att!ihlpb!gregg
loo@mister-curious.sw.mcc.com (Joel Loo) (03/14/89)
In article <252@torch.UUCP>, richard@torch.UUCP (Richard Nuttall) writes: > > ABSOLUTELY!!!! > I HATE vi. > > I have only had to use vi in the last couple of months, before that > I have used decent custmisable editors (WYSIWYG) such as > > VAX TPU (a highly customised version of EVE) > APOLLO dm editor > MICROSOFT C5.1 M editor I hope this is not an editor war but honest discussion of pros and cons of various editors. I have used over a dozen of text editors/word processors. My comments might be useful to some: (take note that I came to use vi only recently, it is my LAST and NOT the first editor.) I am a vi convert (in every sense of the word) after using ZMACS (a more powerful extended version of Emacs) on a certain Lisp machine for over a year and almost 8 hours a day everyday. Before that I used the EDT editor on the Vax for three years and TPU for a while after VMS 4.2 was released (yes I am aware of the programmability of TPU.) I had also use for short periods the VED editor (POPLOG editor, highly programmable too), TRS-80 editor (can't recall the name), TECO, RED (on DEC Rainbow), Xedit (IBM mainframe), Apple ][ editor, Sidekick editor, Smalltalk... [Comment: Programmability is a nice concept but don't stretch it too far. I had the experience of spending more time programming an editor than on my work. One complaint about vi is that it has modes. My view is that modeless editors are nice for beginners, but an old-hand doesn't even realize vi has modes; modes become natural to him. Use of the mouse is, again, nice for beginners, but I find it a pain when I was forced to use it in Smalltalk and Macintosh; I just could not do cutting and pasting as fast as in vi (nothing to do with my agility, it is inherent with mice, a lot of hackers will agree with me).] I had use a few text formatters/word processors too. WYSIWYG: Wordstar, MS word, WordPerfect, PageMaker, FrameMaker. Non- WYSIWYG and non-interactive ones: TeX and Runoff (DEC). [Comment: There are advantages for using WYSIWYG text formatters. There are also disadvantages: they are USUALLY slow and not as flexible as TeX or xxxOff; fully WYSIWYG software encourages time wasting since users do a lot of fine adjustments; most 'WYSIWYG software are not fully WYSIWYG and thus a lot of printing prob- lems ...] Finally, vi is efficient in a lot of operations, especially those that we do 80% of the time during an editing session. There are a lot of useful commands predefined so that one does not have to waste time writing his own macros. Contrary to popular beliefs, vi is programmable (though not as easy and complete), I have written some useful vi macros such as cutting and pasting, alter- nate buffers, etc. (If you are interested I will post it after I tidy them up.) Vi has also a good interface to the Unix shell. (For you info, this message is done entirely in vi, using nroff for justification and spell for spelling check.) Vi is extremely popular in Unix systems, every Unix machine has one. I had at one time or another transferred my vi macros file to Apollo, IBM RT PC, Sun, and it works identically. I could start work on a new Unix machine in no time. I even got hold of a vi on IBM PC so that I do not have to use the SideKick editor (and mind you, that was my PC editor for over three years) that was becoming painful when I have to toggle between PC and Unix. Agree that vi need to be improved. There are certain features that should be included (maybe someone can look into this). My advice is: spend more time reading the vi reference manual. Do not be discouraged from using it just because vi has cryptic com- mands. It serves most programming needs just too well. -------------------------------------------------------------------- Joel Loo Peing Ling composed on Mon Mar 13 10:32:46 CST 1989 -------------------------------------------------------------------- MCC | Email: loo@sw.mcc.com 3500 West Balcones Centre Dr. | Voice: (512)338-3680 (O) Austin, TX 78759 | (512)343-1780 (H)
majka@moose.cs.ubc.ca (Marc Majka) (03/14/89)
gaynor@athos.rutgers.edu (Silver) writes: > [...] For the real long lines, the eye has trouble spotting > the beginning of the next line. [...] > Comments? Additions? How about for the virtual long lines? My eye has a lot of trouble spotting them. Seriously, poor grammer and spelling errors make text very (or should I say "real" :-) difficult to read. The mind stumbles over the garbage. --- Marc Majka
jik@athena.mit.edu (Jonathan I. Kamens) (03/14/89)
In article <9844@ihlpb.ATT.COM> gregg@ihlpb.ATT.COM (Wonderly) writes: >And what happens when you sit down to help somebody with something and they >don't have *macs set up the way you do? Can you shift gears and learn their >brand of mappings in short order? The odds are that if I sit down to help somebody, I'm not going to be doing something so complex that I'm going to run head-on into their emacs bindings. In fact, the odds are that if I'm sitting down to help someone, they don't know enough to have added any major customizations to emacs :-) The fact of that matter is that while many people add custom hacks to their own personal .emacs file, I've never known anyone to decide that ^n and ^p should no longer move up and down a line, or that ^x ^s should no longer save a file. If somebody has hacked their emacs so much that I can't move around it, then they're probably beyond help :-) > If so, you could probably learn vi or >the standard mappings for *macs as well instead of working yourself into a >state of dependence on something that is so incompatible with other >environments. I don't "depend" on the changes I've made to emacs. I like them and they make my work easier, but when my fileserver is down and I have to login without all of my elisp hacks, I can get by quite well, thank you, with mimimal (if any) adjustment. As I said, most people's addition to the standard emacs are *enhancements*, not outright modifications of the emacs command structure. > Seriously, I thought it was common knowledge that right >or wrong standard ways and methods yield common knowledge and higher >productivity! It is only necessary to insure a basic level of common knowledge -- how to move the cursor around, how to save or load a file, how to search for a string or replace it. Once again, as I said above, most people who use emacs don't change these things, and if they do, you can always start up an emacs -q or jove and work with that if you need to help them. > That is precisely why you won't see me using zillions of >aliases and shell scripts. I have a few, but just enough to get by, like >alias ls="ls -CF". If a tool doesn't do the right thing to begin with, >I find it hard to believe that the tool is worthy of being called a tool! I tend to make sure that I know the default behavior and any customized behavior I've constructed for any program that I use. If I am going to help someone else and I suspect that they've made modifications that will conflict with mine, a quick "/bin/csh -f" will put me into a shell with no customizations; if I want, I can even source the .cshrc out of my account and get my environment, or I can work with the defaults, since I know what they are. >The 'right thing' is hard to define, but certainly the fact that so many >people change and add mappings to *macs says something! You seem to think that customizations are an abnormality and something that should be avoided. Modifications to the accepted standards are sometimes a problem, but enhancements are not; if you can't learn to step around somebody's enhancements the few times that you have to, it seems to me that you're just asking to be restricted to only one type of editor -- yours, the way you like it. Jonathan Kamens USnail: MIT Project Athena 410 Memorial Drive, No. 223F jik@Athena.MIT.EDU Cambridge, MA 02139-4318 Office: 617-253-4261 Home: 617-225-8218
barmar@think.COM (Barry Margolin) (03/14/89)
In article <9801@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >The odds are that if I sit down to help somebody, I'm not going to be >doing something so complex that I'm going to run head-on into their >emacs bindings. In fact, the odds are that if I'm sitting down to >help someone, they don't know enough to have added any major >customizations to emacs :-) I used to have a coworker who I helped out quite a bit (often helping him debug his Emacs extensions). He had a whole bunch of extensions to bind the function keys on his Honeywell terminal to common operations. Unfortunately, the escape sequences sent by the function keys conflicted with many standard Emacs key bindings, such as esc-B. This is the only time I've ever had trouble sitting down at someone else's terminal. I think this is more the exception than the rule (even if lots of people bind function keys, most terminals' function keys send multi-character sequences beginning with a common escape sequence so not too many Emacs key bindings are affected). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
lbr@holos0.UUCP (Len Reed) (03/14/89)
In article <7324@boulder.Colorado.EDU> walkerb@tramp.Colorado.EDU (Brian Walker) writes: >Actually, for all of it's clunks and clatters, vi is livable.... >And, you can learn to hit the dreaded [esc] key. I use vi, simply because it is already installed on every Unix or Xenix machine I sit down at, and I can put in on MS-DOS machines (which I sometimes have to deal with). I'm a consultant and spend time on my machines and on various customers machines. The dreaded Escape key is a problem because it's in a different place on every machine. But there's a real easy work-around for that: the '[' is almost always to the right of the 'P', and control-[ is an Ascii escape. I also touch type ^H for backspace and ^I for tab, since those keys wander all over, too. I know a tiny subset of Brief because it's the editor one of my customers is using on his PCs, and it has the utterly brain-damaged "feature" of not liking touch-typed ^H, ^[, etc.; apparantly it cares about the "scan codes." I just seeth when I see a circle when I type ^H. Yeah, I know that Brief's macro capabilities could get me around this, but the only reason I'm using it is because I'm sitting at someone else's PC, so *my* macros wouldn't be there, anyway. Now, does anyone have a solution to idiot keyboard makers that put the caps lock key where the Ctrl key should be? -- - Len Reed
dig@peritek.UUCP (Dave Gotwisner) (03/14/89)
In article <5552@brspyr1.BRS.Com>, miket@brspyr1.BRS.Com (Mike Trout) writes: > In article <9653@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > > > [stuff deleted] > > Well, that's true; everybody has a right to their own opinions and tastes, BUT: > > You can use vi all you want, and it may work just fine for you. Fine; that's > your business. But you should be aware that while you are putt-putting along > in your Sopwith Pup, most of the rest of us have climbed into P-38 Lightnings. > You may be very comfortable with the Pup, but the real world has left you > behind. The Pup may serve you very well the rest of your days, but God help > you if you ever find yourself in serious financial competition with somebody > who uses up-to-date text editors. Fine, I will. One thing VI has that NO (I repeat NO) other editor has that I have used has is a way to help me fix my typos when my dyslexia pops up. Yes, I can do it in other editors with macros, but why, when xp works so well. For the bulk of what I do (writing programs, not documentation), an editor works a lot better for me than a word processor. I have used both. Corporate requirements require that our documentation be done with a specific word processor, and I have no complaints for that, word processors are for word processing, food processors are for food processing, and editors are for editing what is already written (which is a lot of what debugging is). Also, are you saying that you are more facile with a word processor that has the newest and greatest features, and hides the guts from the user than I am (who has been using the VI editing language (emphasis added) for 12 or so years)? On a fair day of programming, I can write and enter 500 - 600 lines of code. On a great day (the rare exception, when I have no customer calls and no flaming to do ;-) ) I have topped out at about 1200 lines. This includes getting the stuff to compile and 8 hour days. Would another word processor speed that up much? I doubt it. Oh, your complaint is that it is old.... Well, English has been around for how many hundreds of years? I guess it is time to invent a new/better language! VI, like the English language, have grown over the years, because there are features that are useful that people have seen have been omitted (I remember when macros were first added, for instance). Also, as far as put-putting in old technology... I used to know someone who drove a Shelby Cobra (60's technology, for sure). I bet you it could still probably blow the doors off of whatever new cars most of netdome drives. > > In the 1970s, vi was the greatest thing since hot fudge sundaes. But check > your calendars. The world moves on, and "it should stay that way" is an > attitude that blows away with the wind every decade or so. I'm sure that this > was the same argument used when transistors began to replace vacuum tubes: > "I like tubes, I'm comfortable with them, and I'm going to continue to use > them. It should stay that way." Guess what happened to all those vacuum tube > freaks? Again, the VI of the 70's is not the VI of today. The original VI fit in 64KB of memory (code+data), could it today? Could your word processor? If an editor or word processor came around today that took no time, whatsoever to learn, and was better than the editors I have on my machines, and was free, I would definitely use it, but since none I know of fits into this catagory, I will happily stick with VI. -- ------------------------------------------------------------------------------ Dave Gotwisner UUCP: ...!unisoft!peritek!dig Peritek Corporation ...!vsi1!peritek!dig 5550 Redwood Road Oakland, CA 94619 Phone: 1-415-531-6500
jw@pan.UUCP (Jamie Watson) (03/14/89)
Ideas about what constitutes a WYSIWYG editor aside, the "sam" editor runs under X, and does everything that you mentioned in your posting. Including position in a file with the mouse, cut/paste/copy text with the mouse, resize windows (editor windows *and* the enclosing X window). It can also have multiple files in multiple windows, multiple windows on a single file (all of which are kept current), and for complex edit tasks it has a truly wonderful command language. For trivial or simple edit tasks, the command language can be ignored, and all work done with the mouse/keyboard. We are currently using it on Vaxstation 2000 and IBM RT/PC, both with X.V11R3. It also comes with front ends for Suntools, and downloadable front ends for blit and 630 terminals. It is available from the AT&T Unix Toolchest (AT&T Unix Europe Ltd.), and costs $100 for a site source license. jw
trb@stag.UUCP ( Todd Burkey ) (03/14/89)
In article <2112@mister-curious.sw.mcc.com> loo@mister-curious.sw.mcc.com (Joel Loo) writes: > >[Comment: Programmability is a nice concept but don't stretch it >too far. I had the experience of spending more time programming >an editor than on my work. One complaint about vi is that it has >modes. My view is that modeless editors are nice for beginners, >but an old-hand doesn't even realize vi has modes; modes become >natural to him. Use of the mouse is, again, nice for beginners, >but I find it a pain when I was forced to use it in Smalltalk and >Macintosh; I just could not do cutting and pasting as fast as in >vi (nothing to do with my agility, it is inherent with mice, a >lot of hackers will agree with me).] I guess I qualify as a hacker and I do agree...up to a point. I use vi, emacs (occasionally), micro-emacs, and Apollo DM edit in my normal programming environment and I have used the Vax editors, various PC and Atari ST editors, and lots of line editors in the past. In the early days of Emacs, I was a 'macro' fanatic, even putting up with the incredibly slow operation of emacs on my IBM PC just to have the same macros running there. About 5 years ago, I found myself in an environment that only had vi and I managed to become a vi addict with very little kicking and screaming (maybe a years worth). I agree that vi is better at single buffer cut and paste than emacs. Vi doesn't have more capability in this area, it is just easier and faster to do cutting and pasting than in emacs (yes, even than in the various emacs vi emulation modes.) Unfortunately, vi doesn't handle multiple buffers in a very usable way (almost as if multiple buffers were an afterthought during the development of vi). I also feel that the phrase "mice are nice, but my finger doesn't linger" is appropriate for most editor operations...except some inter-buffer operations on high resolution, multiple window displays. >Agree that vi need to be improved. There are certain features >that should be included (maybe someone can look into this). My >advice is: spend more time reading the vi reference manual. Do >not be discouraged from using it just because vi has cryptic com- >mands. It serves most programming needs just too well. For years I have waited for a better programming editor. I have seen faster editors on the various PCs, some very well integrated editors coming out with the C and OCCAM development packages on the Atari ST, but nothing that really integrates the programmer into his development environment in Unix. My idea of an ideal editor is one that 1) allows multi-file editing with a clean and fast buffering scheme, 2) fully supports folding, 3) allows the programmer to relate lines and words and use these relationships in a hyper-text like manner (i.e. moving back and forth between a program document and the appropriate lines of code at the press of a few keys), 4) has configurations save and restore modes (so you can get back to EXACTLY the same place you left off editing the day before...with all buffer info intact), and 5) has more intelligence built in (rather than interpreted in macros. What a coincidence :-). Last November I started writing an editor in my spare time, just to see how hard it would be to add a thought processor-like folding concept to an editor. I wrote this editor from scratch, partly to learn why editors act the way they do the hard way, and partly because I had a feeling that the vi or emacs styles would restrict or dictate the implementation of folding. This editor is now in alpha test and will be distributed to the net if it is still bug-free a month from now. The editor does have everything that is currently on my wishlist (see above), but I still regard it as more of a prototype. There are a lot of snazzy features that I would like to add (or see added) to the editor to turn it into a real CASE tool, but my editor will likely need some heavy optimization and maybe even a core logic rewrite first. How do other programmers/hackers out there feel about the need for higher level programming editors/tools? Are you completely happy with your current editor, so things like folding and inter-file relationships aren't really of any foreseeable use? Is moded vs. non-moded really the issue between editors, or is it non-programmable vs. programmable, or does it simply boil down to the actual options and commands you have available in an editor? -Todd Burkey trb@stag.UUCP or ... tburkey@eta.com
tale@pawl.rpi.edu (David C Lawrence) (03/15/89)
In article <561@peritek.UUCP> dig@peritek.UUCP (Dave Gotwisner) writes:
DG> [...] One thing VI has that NO (I repeat NO) other editor has that
DG> I have used has is a way to help me fix my typos when my dyslexia pops up.
DG> Yes, I can do it in other editors with macros, but why, when xp works so
DG> well. [...]
You would think that someone that took the time to double emphasize a
statement would know what he wastalking about. Sorry, but both GNU
and Prime Emacs, and probably most other flavours (but not MicroGNU,
last I checked) have C-t to transpose-chars and M-t to transpose-words.
And, has been pointed out before, you can have vi inside of GNU Emacs
and still have the rest of the Emacs environment available to you.
I've been watching this discussion for a couple of days now without
jumping in with support for my favourite editor. That's mostly
because I think it is important for someone to be happy with an editor
and not everyone likes the same things. But please stopping making
comments that just aren't accurate.
--
tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edubrunjes@isctsse.UUCP (Roy Brunjes) (03/15/89)
In article <2112@mister-curious.sw.mcc.com> loo@mister-curious.sw.mcc.com (Joel Loo) writes: >I am a vi convert (in every sense of the word) after using ZMACS >(a more powerful extended version of Emacs) on a certain Lisp >machine for over a year and almost 8 hours a day everyday. > > [ ... ] > >Agree that vi need to be improved. There are certain features >that should be included (maybe someone can look into this). My >advice is: spend more time reading the vi reference manual. Do >not be discouraged from using it just because vi has cryptic com- >mands. It serves most programming needs just too well. > Just one comment to make here: A Sun techie doing some consulting with me pointed out that even Bill Joy (creator of vi) doesn't use Vi anymore. He uses GNU Emacs. As a GNU Emacs user, I admit that the LISP-like syntax used to "program" Emacs is non-intuitive to a non-LISP programmer like myself, but I have to do precious little of that anyway (4 lines in my .emacs file). I have had to live with Vi because it *IS* on almost any UNIX system I go to, but that doesn't mean that I have to like it! Roy Brunjes ...rochester!kodak!kadsma!brunjes Disclaimer: These opinions are my own. My employer doesn't even know I have opinions about such things and consequently couldn't begin to endorse them.
loo@mister-curious.sw.mcc.com (Joel Loo) (03/15/89)
Here are some vi macros. They are very general and are good for beginners.
Unpack them as normal archive.
Comments and suggestions are welcomed. - Joel Loo
#! /bin/sh
# This is a shell archive. Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by mister-curious.sw.mcc.com!loo on Tue Mar 14 11:05:23 CST 1989
# Contents: README jl.ex jl.ex.ref
echo x - README
sed 's/^@//' > "README" <<'@//E*O*F README//'
These are some example vi macros.
The simplicity and usefulness of these examples make
them good examples for vi beginners. I hope these
macros would make life worth living once more for lots
of vi beginners.
You can either include the "jl.ex" file into your
vi init file ".exrc" or use the vi command ":source jl.ex"
to load them during your vi session.
Comment and suggestions are welcomed.
- Joel Loo Peing Ling, Mar 14, 89
@//E*O*F README//
chmod u=rw,g=r,o=r README
echo x - jl.ex
sed 's/^@//' > "jl.ex" <<'@//E*O*F jl.ex//'
"Some vi macros
"Joel Loo, Feb 15 1989
map V :s$/\* \(.*\) \*/$\1$
map v :s$.*$/* & */$
map W mt`m"dy`t
map mt`m"dd`t
map Y "dPmm
map K :'m,.s/.*/# &/
map :'m,.s/# \(.*\)/\1/
map :e#
abbr cmt /* */hhi
abbr dcm /*
abbr ilv I love vi
map ip oprintf(" >\n");4hi
@//E*O*F jl.ex//
chmod u=rw,g=r,o=r jl.ex
echo x - jl.ex.ref
sed 's/^@//' > "jl.ex.ref" <<'@//E*O*F jl.ex.ref//'
////////////////////////////////////////////////////////////////////////
/ EXAMPLES VI MACROS REF. (by loo@mcc.com) /
////////////////////////////////////////////////////////////////////////
////////////////////
/ cut-paste macros /
////////////////////
[The command "mm" marks the starting line of a cut/copy. After proper
marking, move the cursor to the ending line of your cut/copy. Use either
"^W" or "W" to get the text cut/copied. The command "Y" yanks the cut/
copied text at the cursor position. These commands work across files,
unlike the "*y" and "p"/"P" commands.]
Command | Meaning
-----------------------------------------------------------------------
mm | Mark the beginning of region
W | Copy (to scratch) from marked line to current line
^W | Cut (to scratch) from marked line to current line
Y | Yank (or paste) from scratch area
//////////////
/ commenting /
//////////////
v | 'C'-comment the current line
V | 'C'-uncomment the current line
K | Comment with '#' from marked line (good for sh etc.)
^K | Uncomment lines of '#' from mark line (")
/////////////////
/ Miscellaneous /
/////////////////
^O | Edit the alternate file
/////////////////
/ abbreviations /
/////////////////
[Abbreviation capability is part of vi. The user can define as many as
he likes with the ex-command "abbr". Abbreviation works when the exact
sequence of chars is typed in the insert mode.]
[Important: Need to be in insert mode]
Abbreviation | Expansion
-------------------------------------------------------------------------------
ilv | "I love vi"
cmt | "/* */" and ready for inserting comment text
dcm | similar to cmt but for C-function documentation
///////////////////
/ Escape Commands /
///////////////////
[Escape commands capability is not documented but only implied by vi reference.
This function might not be in some vi implementations. Using these commands
requires fast fingering; you have to press <esc> and following by the rest
of a command in quick succession.]
Command | Meangin
-------------------------------------------------------------------------------
<esc>ip | Insert 'printf(" >\n");' and ready for inserting print text
[Escape commands capability comes in handy when all control and function
keys of your keyboard are defined. You can define almost unlimited escape
commands.]
@//E*O*F jl.ex.ref//
chmod u=rw,g=r,o=r jl.ex.ref
echo x - jl.ex.shar
sed 's/^@//' > "jl.ex.shar" <<'@//E*O*F jl.ex.shar//'
# This is a shell archive. Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by mister-curious.sw.mcc.com!loo on Tue Mar 14 11:05:23 CST 1989
# Contents: README jl.ex jl.ex.ref jl.ex.shar
echo x - README
sed 's/^@//' > "README" <<'@//E*O*F README//'
These are some example vi macros.
The simplicity and usefulness of these examples make
them good examples for vi beginners. I hope these
macros would make life worth living once more for lots
of vi beginners.
You can either include the "jl.ex" file into your
vi init file ".exrc" or use the vi command ":source jl.ex"
to load them during your vi session.
Comment and suggestions are welcomed.
- Joel Loo Peing Ling, Mar 14, 89
@@//E*O*F README//
chmod u=rw,g=r,o=r README
echo x - jl.ex
sed 's/^@//' > "jl.ex" <<'@//E*O*F jl.ex//'
"Some vi macros
"Joel Loo, Feb 15 1989
map V :s$/\* \(.*\) \*/$\1$
map v :s$.*$/* & */$
map W mt`m"dy`t
map mt`m"dd`t
map Y "dPmm
map K :'m,.s/.*/# &/
map :'m,.s/# \(.*\)/\1/
map :e#
abbr cmt /* */hhi
abbr dcm /*
abbr ilv I love vi
map ip oprintf(" >\n");4hi
@@//E*O*F jl.ex//
chmod u=rw,g=r,o=r jl.ex
echo x - jl.ex.ref
sed 's/^@//' > "jl.ex.ref" <<'@//E*O*F jl.ex.ref//'
////////////////////////////////////////////////////////////////////////
/ EXAMPLES VI MACROS REF. (by loo@mcc.com) /
////////////////////////////////////////////////////////////////////////
////////////////////
/ cut-paste macros /
////////////////////
[The command "mm" marks the starting line of a cut/copy. After proper
marking, move the cursor to the ending line of your cut/copy. Use either
"^W" or "W" to get the text cut/copied. The command "Y" yanks the cut/
copied text at the cursor position. These commands work across files,
unlike the "*y" and "p"/"P" commands.]
Command | Meaning
-----------------------------------------------------------------------
mm | Mark the beginning of region
W | Copy (to scratch) from marked line to current line
^W | Cut (to scratch) from marked line to current line
Y | Yank (or paste) from scratch area
//////////////
/ commenting /
//////////////
v | 'C'-comment the current line
V | 'C'-uncomment the current line
K | Comment with '#' from marked line (good for sh etc.)
^K | Uncomment lines of '#' from mark line (")
/////////////////
/ Miscellaneous /
/////////////////
^O | Edit the alternate file
/////////////////
/ abbreviations /
/////////////////
[Abbreviation capability is part of vi. The user can define as many as
he likes with the ex-command "abbr". Abbreviation works when the exact
sequence of chars is typed in the insert mode.]
[Important: Need to be in insert mode]
Abbreviation | Expansion
-------------------------------------------------------------------------------
ilv | "I love vi"
cmt | "/* */" and ready for inserting comment text
dcm | similar to cmt but for C-function documentation
///////////////////
/ Escape Commands /
///////////////////
[Escape commands capability is not documented but only implied by vi reference.
This function might not be in some vi implementations. Using these commands
requires fast fingering; you have to press <esc> and following by the rest
of a command in quick succession.]
Command | Meangin
-------------------------------------------------------------------------------
<esc>ip | Insert 'printf(" >\n");' and ready for inserting print text
[Escape commands capability comes in handy when all control and function
keys of your keyboard are defined. You can define almost unlimited escape
commands.]
@@//E*O*F jl.ex.ref//
chmod u=rw,g=r,o=r jl.ex.refaad@stpstn.UUCP (Anthony A. Datri) (03/15/89)
>> I have only had to use vi in the last couple of months, before that >> I have used decent custmisable editors (WYSIWYG) such as >> APOLLO dm editor COUGH CHOKE RETCH PUKE VOMIT You're joking, right? Apollo's editor doesn't even know what tabs are. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, my VT05, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
gillies@p.cs.uiuc.edu (03/15/89)
Which editor is best? Whichever you've learned.
I learned xed, MIT emacs, Gosling's emacs, vi, then gnuemacs. Each
time I get a new emacs, I make it emulate the features I'm accustomed
to in the old emacs. This way, I can take advantage of any emacs
without having to learn an entirely new editor.
You can argue about the things you enjoy most in your editor
-- I like incremental search in emacs (easily added to vi)
-- most emacs's are programmed to NEVER complain about huge
files, huge lines, etc. Some other editors are not as robust.
-- I like using ESC-J to justify my paragraphs. Someday
I'm going to modify it to avoid justifying troff macros.
-- I use 2 windows all the time in emacs.
-- I occasionally run a shell in a window to record a session
-- Emacs commands seem to operate on "words" more than on characters,
as in vi. Most of my documents are strings of words, and even
sentences sometimes. I understand that many vi documents are just
strings of characters 8-).
The things I like about VI are
-- I used to appreciate its incredible speed. It can maintain
the screen while using VERY FEW cpu cycles. Unfortunately,
this "feature" is rapidly becoming obsolete, with cray-1's
on a chip being introduced every day.
-- It's not a memory pig like emacs.
-- It's upward compatible with ed and xed, two editors I used to
use. When the ed/xed users die, this will not be an advantage
-- it is distributed free with most unix systems. You can't
beat this convenience.
-- It is more faithful to the UNIX user-interface (*snicker*).
vi would be a poor-man's editor on a non-unix system.
emacs has much more capability "built in".steinar@fdmetd.uucp (Steinar Overbeck Cook) (03/15/89)
In article <2112@mister-curious.sw.mcc.com>, loo@mister-curious.sw.mcc.com (Joel Loo) writes: > In article <252@torch.UUCP>, richard@torch.UUCP (Richard Nuttall) writes: > > > > ABSOLUTELY!!!! > > I HATE vi. > [ Lots of text deleted ...] I agree on almost everything that Richard Nuttall wrote. Personally I have been using NewWord, Wordstar, RED, ISPF (IBM), XEDIT, Brief and so on... When I think of it, it is two things I would like to see in 'vi'. Coloumn cut-and-paste (with the marked block in standout or inverse video) and the ability to edit more than two files simultaneously. -- Steinar Overbeck Cook, Fellesdata a.s, P.O. Box 248, 0212 OSLO 2, NORWAY Phone : +47 2 52 80 80 Fax : +47 2 52 85 10 E-mail : ...!mcvax!ndosl!fdmetd!steinar or steinar@fdmetd.uucp <The opinions expressed, if any, do not represent Fellesdata a.s>
zavras@cleo.cs.wisc.edu (Alexios Zavras) (03/16/89)
In article <252@torch.UUCP> richard@torch.UUCP (Richard Nuttall) writes: >>From Ted Holden, HTE: [...] >>and just get rid of vi which, along with nroff and troff and a couple > >ABSOLUTELY!!!! >I HATE vi. > [...] >I have tried JOVE and am looking at CRISP, but what I really want >is one that, when running X, you can use the mouse to copy around >text, point to a place in the text, and resize windows dynamically >without blowing up the editor. I have heard that a GNU EMACS can do >at least some of this, and am trying to get the sources at the moment. [...] Eh ??? Excuse me, but vi can do all that (and a lot more, too :-). It surely understands window resizes (SIGWINCH) (but what "dynamically" means ?), you can go to any point by clicking the mouse (:set xmouse), and you can copy around text using the mouse as always in the X Window Environment... I'm sure GNU emacs can too all that, too, but I am not (yet) a "knowledgeable user", so I can't provide details... Therefore, I remain a vi-fanatic_lover, >Richard Nuttall | ukc!stc!datlog!torch!richard -- zvr - +-----------------------+ Alexios Zavras (-zvr-) | Life is once, forever | zavras@cs.wisc.edu +-----------------H C-B-+
loo@mister-curious.sw.mcc.com (Joel Loo) (03/16/89)
I received messages that say right-justified text is hard to read. I realized that before I was born. I was only showing off what I can do with vi: it can even call nroff to justify text. Anyway, someone said that he does not even want to read my article if it is so neatly formatted (me too, I could not read it after I nroffed it - gave me a headache). So, time to show off again. I reformatted it with 'fmt' (no cheating, within vi again) from the original right-justified article which was earlier nroffed from the unformatted article: --------- skip if you have read the --------- ------- right-justified version before ------ In article <252@torch.UUCP>, richard@torch.UUCP (Richard Nuttall) writes: > > ABSOLUTELY!!!! > I HATE vi. > > I have only had to use vi in the last couple of months, before that > I have used decent custmisable editors (WYSIWYG) such as > > VAX TPU (a highly customised version of EVE) > APOLLO dm editor > MICROSOFT C5.1 M editor I hope this is not an editor war but honest discussion of pros and cons of various editors. I have used over a dozen of text editors/word processors. My comments might be useful to some: (take note that I came to use vi only recently, it is my LAST and NOT the first editor.) I am a vi convert (in every sense of the word) after using ZMACS (a more powerful extended version of Emacs) on a certain Lisp machine for over a year and almost 8 hours a day everyday. Before that I used the EDT editor on the Vax for three years and TPU for a while after VMS 4.2 was released (yes I am aware of the programmability of TPU.) I had also use for short periods the VED editor (POPLOG editor, highly programmable too), TRS-80 editor (can't recall the name), TECO, RED (on DEC Rainbow), Xedit (IBM mainframe), Apple ][ editor, Sidekick editor, Smalltalk... [Comment: Programmability is a nice concept but don't stretch it too far. I had the experience of spending more time programming an editor than on my work. One complaint about vi is that it has modes. My view is that modeless editors are nice for beginners, but an old-hand doesn't even realize vi has modes; modes become natural to him. Use of the mouse is, again, nice for beginners, but I find it a pain when I was forced to use it in Smalltalk and Macintosh; I just could not do cutting and pasting as fast as in vi (nothing to do with my agility, it is inherent with mice, a lot of hackers will agree with me).] I had use a few text formatters/word processors too. WYSIWYG: Wordstar, MS word, WordPerfect, PageMaker, FrameMaker. Non-WYSIWYG and non-interactive ones: TeX and Runoff (DEC). [Comment: There are advantages for using WYSIWYG text formatters. There are also disadvantages: they are USUALLY slow and not as flexible as TeX or xxxOff; fully WYSIWYG software encourages time wasting since users do a lot of fine adjustments; most 'WYSIWYG software are not fully WYSIWYG and thus a lot of printing problems ...] Finally, vi is efficient in a lot of operations, especially those that we do 80% of the time during an editing session. There are a lot of useful commands predefined so that one does not have to waste time writing his own macros. Contrary to popular beliefs, vi is programmable (though not as easy and complete), I have written some useful vi macros such as cutting and pasting, alternate buffers, etc. (If you are interested I will post it after I tidy them up.) Vi has also a good interface to the Unix shell. (For you info, this message is done entirely in vi, using nroff for justification and spell for spelling check.) Vi is extremely popular in Unix systems, every Unix machine has one. I had at one time or another transferred my vi macros file to Apollo, IBM RT PC, Sun, and it works identically. I could start work on a new Unix machine in no time. I even got hold of a vi on IBM PC so that I do not have to use the SideKick editor (and mind you, that was my PC editor for over three years) that was becoming painful when I have to toggle between PC and Unix. Agree that vi need to be improved. There are certain features that should be included (maybe someone can look into this). My advice is: spend more time reading the vi reference manual. Do not be discouraged from using it just because vi has cryptic commands. It serves most programming needs just too well. -------------------------------------------------------------------- Joel Loo Peing Ling composed on Mon Mar 13 10:32:46 CST 1989 -------------------------------------------------------------------- MCC | Email: loo@sw.mcc.com 3500 West Balcones Centre Dr. | Voice: (512)338-3680 (O) Austin, TX 78759 | (512)343-1780 (H)
loo@mister-curious.sw.mcc.com (Joel Loo) (03/16/89)
Due to my ignorance with the fact that control characters can be eaten up
across network, I have to do the posting of the example vi macros again.
Here are some vi macros. They are very general and are good for beginners.
Comments and suggestions are welcomed. - Joel Loo
Instruction to retrieve:
1. cut along the cut line and save to a file
2. use 'uudecode file' giving file 'JL.shar'
3. use 'sh JL.shar' to unpack the sh archive
Thanks for you patience. I hope this works.
-------------------- cut here -------------------
begin 666 JL.shar
M(R!4:&ES(&ES(&$@<VAE;&P@87)C:&EV92X@(%)E;6]V92!A;GET:&EN9R!B
M969O<F4@=&AI<R!L:6YE+ HC('1H96X@=6YP86-K(&ET(&)Y('-A=FEN9R!I
M="!I;B!A(&9I;&4@86YD('1Y<&EN9R B<V@@9FEL92(N"B,*(R!7<F%P<&5D
M(&)Y(&UI<W1E<BUC=7)I;W5S+G-W+FUC8RYC;VTA;&]O(&]N(%=E9"!-87(@
M,34@,3$Z,3@Z,S,@0U-4(#$Y.#D*(R!#;VYT96YT<SH@(%)%041-12!J;"YE
M>"!J;"YE>"YR968*( IE8VAO('@@+2!214%$344*<V5D("=S+UY +R\G(#X@
M(E)%041-12(@/#PG0"\O12I/*D8@4D5!1$U%+R\G"E1H97-E(&%R92!S;VUE
M(&5X86UP;&4@=FD@;6%C<F]S+@I4:&4@<VEM<&QI8VET>2!A;F0@=7-E9G5L
M;F5S<R!O9B!T:&5S92!E>&%M<&QE<R!M86ME"G1H96T@9V]O9"!E>&%M<&QE
M<R!F;W(@=FD@8F5G:6YN97)S+B!)(&AO<&4@=&AE<V4*;6%C<F]S('=O=6QD
M(&UA:V4@;&EF92!W;W)T:"!L:79I;F<@;VYC92!M;W)E(&9O<B!L;W1S"F]F
M('9I(&)E9VEN;F5R<RX@"@I9;W4@8V%N(&5I=&AE<B!I;F-L=61E('1H92 B
M:FPN97@B(&9I;&4@:6YT;R!Y;W5R( IV:2!I;FET(&9I;&4@(BYE>')C(B!O
M<B!U<V4@=&AE('9I(&-O;6UA;F0@(CIS;W5R8V4@:FPN97@B"G1O(&QO860@
M=&AE;2!D=7)I;F<@>6]U<B!V:2!S97-S:6]N+@H*0V]M;65N="!A;F0@<W5G
M9V5S=&EO;G,@87)E('=E;&-O;65D+@H*(" @(" @(" @(" @(" @(" @("T@
M2F]E;"!,;V\@4&5I;F<@3&EN9RP@36%R(#$T+" X.0I +R]%*D\J1B!214%$
M344O+PIC:&UO9"!U/7)W+&<]<BQO/7(@4D5!1$U%"B *96-H;R!X("T@:FPN
M97@*<V5D("=S+UY +R\G(#X@(FIL+F5X(B \/"= +R]%*D\J1B!J;"YE>"\O
M)PHB4V]M92!V:2!M86-R;W,*(DIO96P@3&]O+"!&96(@,34@,3DX.0IM87 @
M5B Z<R0O7"H@7"@N*EPI(%PJ+R1<,20-*PIM87 @=B Z<R0N*B0O*B F("HO
M) TK"FUA<"!7(&UT8&TB9'E@= IM87 @%R!M=&!M(F1D8'0*;6%P(%D@(F10
M;6T*;6%P($L@.B=M+"YS+RXJ+R,@)B\-"FUA<" +(#HG;2PN<R\C(%PH+BI<
M*2]<,2\-"FUA<" /(#IE(PT*86)B<B!C;70@+RH@*B\;:&AI"F%B8G(@9&-M
M("\J#2 J( T@*B\;:T$*86)B<B!I;'8@22!L;W9E('9I"FUA<" ;:7 @;W!R
M:6YT9B@B(" ^7&XB*3L;-&AI"D O+T4J3RI&(&IL+F5X+R\*8VAM;V0@=3UR
M=RQG/7(L;SUR(&IL+F5X"B *96-H;R!X("T@:FPN97@N<F5F"G-E9" G<R]>
M0"\O)R ^(")J;"YE>"YR968B(#P\)T O+T4J3RI&(&IL+F5X+G)E9B\O)PHO
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\*+R @(" @(" @(" @(" @(" @
M($5804U03$53(%9)($U!0U)/4R!2148N("AB>2!L;V] ;6-C+F-O;2D@(" @
M(" @(" @(" O"B\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+PH*"B\O+R\O
M+R\O+R\O+R\O+R\O+R\O"B\@8W5T+7!A<W1E(&UA8W)O<R O"B\O+R\O+R\O
M+R\O+R\O+R\O+R\O"EM4:&4@8V]M;6%N9" B;6TB(&UA<FMS('1H92!S=&%R
M=&EN9R!L:6YE(&]F(&$@8W5T+V-O<'DN($%F=&5R('!R;W!E<@IM87)K:6YG
M+"!M;W9E('1H92!C=7)S;W(@=&\@=&AE(&5N9&EN9R!L:6YE(&]F('EO=7(@
M8W5T+V-O<'DN(%5S92!E:71H97(*(EY7(B!O<B B5R(@=&\@9V5T('1H92!T
M97AT(&-U="]C;W!I960N(%1H92!C;VUM86YD(")9(B!Y86YK<R!T:&4@8W5T
M+PIC;W!I960@=&5X="!A="!T:&4@8W5R<V]R('!O<VET:6]N+B!4:&5S92!C
M;VUM86YD<R!W;W)K(&%C<F]S<R!F:6QE<RP*=6YL:6ME('1H92 B*GDB(&%N
M9" B<"(O(E B(&-O;6UA;F1S+ET*"B!#;VUM86YD"7P@365A;FEN9PHM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0H@;6T)"7P@36%R:R!T:&4@8F5G:6YN
M:6YG(&]F(')E9VEO;@H@5PD)?"!#;W!Y("AT;R!S8W)A=&-H*2!F<F]M(&UA
M<FME9"!L:6YE('1O(&-U<G)E;G0@;&EN90H@7E<)"7P@0W5T("AT;R!S8W)A
M=&-H*2!F<F]M(&UA<FME9"!L:6YE('1O(&-U<G)E;G0@;&EN90H@60D)?"!9
M86YK("AO<B!P87-T92D@9G)O;2!S8W)A=&-H(&%R96$*"B\O+R\O+R\O+R\O
M+R\O"B\@8V]M;65N=&EN9R O"B\O+R\O+R\O+R\O+R\O"@H@=@D)?" G0R<M
M8V]M;65N="!T:&4@8W5R<F5N="!L:6YE"B!6"0E\("=#)RUU;F-O;6UE;G0@
M=&AE(&-U<G)E;G0@;&EN90H@2PD)?"!#;VUM96YT('=I=&@@)R,G(&9R;VT@
M;6%R:V5D(&QI;F4@*&=O;V0@9F]R('-H(&5T8RXI"B!>2PD)?"!5;F-O;6UE
M;G0@;&EN97,@;V8@)R,G(&9R;VT@;6%R:R!L:6YE("@B*2 *"B\O+R\O+R\O
M+R\O+R\O+R\O"B\@36ES8V5L;&%N96]U<R O"B\O+R\O+R\O+R\O+R\O+R\O
M"@H@7D\)"7P@161I="!T:&4@86QT97)N871E(&9I;&4*"B\O+R\O+R\O+R\O
M+R\O+R\O"B\@86)B<F5V:6%T:6]N<R O"B\O+R\O+R\O+R\O+R\O+R\O"EM!
M8F)R979I871I;VX@8V%P86)I;&ET>2!I<R!P87)T(&]F('9I+B!4:&4@=7-E
M<B!C86X@9&5F:6YE(&%S(&UA;GD@87,*:&4@;&EK97,@=VET:"!T:&4@97@M
M8V]M;6%N9" B86)B<B(N($%B8G)E=FEA=&EO;B!W;W)K<R!W:&5N('1H92!E
M>&%C= IS97%U96YC92!O9B!C:&%R<R!I<R!T>7!E9"!I;B!T:&4@:6YS97)T
M(&UO9&4N70H*6TEM<&]R=&%N=#H@3F5E9"!T;R!B92!I;B!I;G-E<G0@;6]D
M95T*"B!!8F)R979I871I;VX)?"!%>'!A;G-I;VX*+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+0H@:6QV( D)?" B22!L;W9E('9I(@H@8VUT
M( D)?" B+RH@*B\B(&%N9"!R96%D>2!F;W(@:6YS97)T:6YG(&-O;6UE;G0@
M=&5X= H@9&-M( D)?"!S:6UI;&%R('1O(&-M="!B=70@9F]R($,M9G5N8W1I
M;VX@9&]C=6UE;G1A=&EO;@H*+R\O+R\O+R\O+R\O+R\O+R\O+PHO($5S8V%P
M92!#;VUM86YD<R O"B\O+R\O+R\O+R\O+R\O+R\O+R\*6T5S8V%P92!C;VUM
M86YD<R!C87!A8FEL:71Y(&ES(&YO="!D;V-U;65N=&5D(&)U="!O;FQY(&EM
M<&QI960@8GD@=FD@<F5F97)E;F-E+@I4:&ES(&9U;F-T:6]N(&UI9VAT(&YO
M="!B92!I;B!S;VUE('9I(&EM<&QE;65N=&%T:6]N<RX@57-I;F<@=&AE<V4@
M8V]M;6%N9',*<F5Q=6ER97,@9F%S="!F:6YG97)I;F<[('EO=2!H879E('1O
M('!R97-S(#QE<V,^(&%N9"!F;VQL;W=I;F<@8GD@=&AE(')E<W0*;V8@82!C
M;VUM86YD(&EN('%U:6-K('-U8V-E<W-I;VXN70H*($-O;6UA;F0@(" @(" @
M('P@365A;F=I;@HM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M"B \97-C/FEP"7P@26YS97)T("=P<FEN=&8H(B @/EQN(BD[)R!A;F0@<F5A
M9'D@9F]R(&EN<V5R=&EN9R!P<FEN="!T97AT"@I;17-C87!E(&-O;6UA;F1S
M(&-A<&%B:6QI='D@8V]M97,@:6X@:&%N9'D@=VAE;B!A;&P@8V]N=')O;"!A
M;F0@9G5N8W1I;VX*:V5Y<R!O9B!Y;W5R(&ME>6)O87)D(&%R92!D969I;F5D
M+B!9;W4@8V%N(&1E9FEN92!A;&UO<W0@=6YL:6UI=&5D(&5S8V%P90IC;VUM
M86YD<RY="D O+T4J3RI&(&IL+F5X+G)E9B\O"F-H;6]D('4]<G<L9SUR+&\]
5<B!J;"YE>"YR968*( IE>&ET(# *
endgaynor@athos.rutgers.edu (Silver) (03/16/89)
> How do other programmers/hackers out there feel about the need for higher > level programming editors/tools? Absolutely essential. > Are you completely happy with your current editor, Yes, GNU Emacs. It's kind of funny that GNU Emacs provides a much better programming environment for its Lisp extension language than Unix does for its shells and utility languages (like awk and sed). > so things like folding and inter-file relationships aren't really of any > foreseeable use? `Folding', in your sense, is a way to arbitrarily selectively displaying portions of a buffer? It's in GNU, and is extremely useful. (GNUsers, note the function narrow-to-region and the variable selective-display.) > Is moded vs. non-moded really the issue between editors No, that's an issue between users and how they bind their keys, unless the editors in question do not provide arbitrary keysequence rebinding. (This is invariably present in programmable editors.) > or is it non-programmable vs. programmable Yes! > or does it simply boil down to the actual options and commands you have > available in an editor? Yes, which is why programmability is so important. When someone gets fed up with a missing or deficient feature, s/he can program it the way they want it and can make the code available to others. Regards, [Ag] gaynor@rutgers.edu
toma@tekgvs.LABS.TEK.COM (Tom Almy) (03/16/89)
I think most people like the first editor they used regularly -- if you started with vi, you won't like EMACS, and visa versa. Personally, nothing beats a keypunch for cut-and-paste editing. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply (this article written using EMACS, because I don't have TECO anymore)
sawant@nunki.usc.edu (Abhay Sawant) (03/16/89)
In article <TALE.89Mar14114703@imagine.pawl.rpi.edu> tale@pawl.rpi.edu writes: > >I've been watching this discussion for a couple of days now without >jumping in with support for my favourite editor. That's mostly >because I think it is important for someone to be happy with an editor >and not everyone likes the same things. But please stopping making >comments that just aren't accurate. >-- > tale@rpitsmts.bitnet, tale%mts@rpitsgw.rpi.edu, tale@pawl.rpi.edu I think this leads up to my best reason why 'Unix needs a real text editor': it's just that editors are very much a question of personal taste; a small set of editors cannot possibly satisfy all users. I think this is a very strong aspect of the PC and the Mac vs. Unix: that if i want to use a text editor of any crazy flavour: whether small, fast, configurable, WYSIWYG, DTP, environment, etc, i can find one which suits my needs. In fact, i regularly move between WordStar, WordPerfect, the primitive editing within Ventura, SideKick, Turbo Pascal and Brief depending on exactly what i'm doing. I think being forced to use one of Emacs or vi is primitive (this is apart from my personal antipathy for both). -ajay
barnett@crdgw1.crd.ge.com (Bruce Barnett) (03/16/89)
In article <167@isctsse.UUCP>, brunjes@isctsse (Roy Brunjes) writes: >Just one comment to make here: A Sun techie doing some consulting with me >pointed out that even Bill Joy (creator of vi) doesn't use Vi anymore. He >uses GNU Emacs. Bill Joy also said that he regrets making vi modal. If he knew more about modeless editors like emacs, he would have hacked together a different beast. Let's face it, vi was done as a quick hack by a programmer who was frustrtated by using ed (ex?) and who had dozens of different terminals all over. But it does have several nice features for being a hack. Compared to other editors I was using at the time, it was quite powerful to one who mastered it. -- Bruce G. Barnett barnett@ge-crd.ARPA, barnett@steinmetz.ge.com uunet!steinmetz!barnett
trb@stag.UUCP ( Todd Burkey ) (03/17/89)
In article <Mar.15.13.17.00.1989.4476@athos.rutgers.edu> gaynor@athos.rutgers.edu (Silver) writes: > >`Folding', in your sense, is a way to arbitrarily selectively displaying >portions of a buffer? It's in GNU, and is extremely useful. (GNUsers, note >the function narrow-to-region and the variable selective-display.) > Unfortunately, folding in GNU, as you are referring to it, isn't much use (unless things have changed drastically in a newer version of GNU Emacs than I have). Folding really becomes useful when all the things you have folded are carried across between edit sessions and when all the 'commands' in the editor really 'understand' folding. For example, I normally keep all my comment blocks folded away, plus any sections of code that I am not currently working on. During block/line copies or moves, things that are folded will remain folded, even if they are moved to other buffers or even into the trashcan. If I fold a block of text or an indented region, I can insert several spaces in front of the resulting 'highlighted' text line, unfold the line and see the entire block shifted to the right by that number of spaces. With a single keypress, I can temporarily unfold everything to perform searches or global substitutions, and then refold everything with another single keypress. And there are many endcase things the editor ends up worrying about (going to marks/relations that are inside of folded text, keeping track of heirarchical folds, etc). At one time I looked at creating a 'map file' for GNU Emacs to use to control folding, but things got just too hairy. And since I didn't like the idea of embedding special characters inside of my source files to 'help out' the editor, I ended up writing FOLDED to see how useful true folding would be and what the ramifications folding had on editor operations. As a result of going through this 'exercise', I do feel that some major changes to the current two big editors (vi and Emacs) would be required to allow incorporation of true folding (and relational features for that matter). From a programming editor viewpoint (note that I said programming, not programmable), I tend to rank editors as follows: vi <-> assembly code...small, fast, concise, and confusing as hell unless you are a vi guru (I get by)...but it comes free with every system. emacs <-> basic...big, slow, but you can do a lot of reprogramming around the rich command set...note that this is interpreted tokenized basic, not compiled. pc-eds<-> forth...smaller, faster, and more application specific editors, some of which are heavily integrated into their respective C, Pascal, Occam, Assembly environments. These editors usually get written for the PC market (where the money is) and later get moved in some form back to Unix (either as a package or emulated under emacs). cased <-> C...a higher level (case) editor that allows truly compiled-in modules and integrates nicely into the environment. This editor would be both programmable and extensible (i.e you can not only program based on the current libc.a, but you can also develop your own low level routines if you need to). Unfortunately, I still haven't found such an editor. My folding editor probably falls back under the realm of the pc-eds, since it doesn't have a user-programming layer. Several people have sent me mail under the assumption that my editor is programmable, probably because I call it a programming editor. It is NOT programmable. My first goal in developing the editor was to put the features of various editors that I liked into the heart of the editor itself. At a later date, I may look into allowing C modules to be linked into the editor (i.e. compiled macros), but that will require some heavy duty restructuring and 'fool-proofing' of the editor itself...not to mention some heavy duty learning on my part. -Todd Burkey trb@stag.UUCP
loo@mister-curious.sw.mcc.com (Joel Loo) (03/17/89)
In article <743@stag.UUCP>, trb@stag.UUCP ( Todd Burkey ) writes: > > ... I was a 'macro' fanatic, even putting up with > the incredibly slow operation of emacs on my IBM PC just to have the > same macros running there. I was a macro fanatic and still am but I am also wiser now not to go for every 'nice' thing. Yes, I think vi is deficient in macro creation power. It does not have a proper macro language. You can't even have if-then-else (or am I wrong?). For the issue of extremely programmable editors, perhaps we can find an analogy in the language Forth. I was a Forth fanatic few years back because it claims to be "an assemble, compiler and even a compiler-compiler." It even "encourages the user to modify its syntax." Sound like a good idea? But this is also the same reason I abandoned Forth. Everybody can has his own Forth language (or languages) even if they started from the same Forth standard. I had difficulties maintaining the few applications and routines I developed because syntax varies. A way round this is to have _standards_ frozen along the course of history. Eg. Postscript and NeWS more or less are frozen Forth dialects/variants. Back to programmable editor. The success and popularity (among those who can behold its beauty) of vi might be because of its non-programmabilty. The philosophy might be stated as: vi provides the necessary features for daily programming chores; it encourages only short user macros so that all vi's behave in more or less the same way; if you want to do more than what you can with vi, look to other unix tools (sed, awk, or even lex and yacc) - vi has a hook to these tools. So, programmability of editors -- tough decision. > ... Unfortunately, vi doesn't handle > multiple buffers in a very usable way (almost as if multiple buffers > were an afterthought during the development of vi). Agree. Only two file buffers are available in vi. At a closer look they are not buffers at all, they are mere illusions. There are other buffers though, the text registers. The registers are, I suspect, hardly used by users, even experts. The reason: too many keystrokes are required to make use of them. I only use them in macros. vi should have better multi-buffering capability. > ... Last November I started writing an editor in my > spare time, just to see how hard it would be to add a thought > processor-like folding concept to an editor. Great! Hope to see you post your editor soon. > How do other programmers/hackers out there feel about the need for > higher level programming editors/tools? I am not too sure what you meant by "higer level". But if it is what I perceived, then, yes, there is a need. A feature like Emacs' "mark the next Sexp" is more civilized to than: "mark beginning, move, move, move ... mark ending". In vi: "ctK" (change to the char 'K') is more civilized than: "del, del, del ... (oops! overshot) undo, undo, (ahhh), type, type, type, type" The important auto-indentation feature (for C and Lisp) are lacking in vi. (Or is there a unix tool to do that?) Even higher level features (which I can't imagine at the moment) can be included. > ... Are you completely happy with > your current editor, so things like folding and inter-file > relationships aren't really of any foreseeable use? Happy, yes. But not _completely_. Folding and interfile relationships would be useful if they are elegant and not confusing. I said 'not confusing' because I have the bad experience of throwing out when I saw a imbecile context-sensitive editor for Pascal, they are for imbecile novice. It has remarkably poor implementation of folding and expansion which work at the moment and location which you least expect. > ... Is moded vs. > non-moded really the issue between editors, I like the moded nature of vi. Modes are good for expert users, allowing them to do things faster. The feeling I get from not having to type control keys to move around is really nice. I have grown out of using the arrow keys too. They are too far away to be reached and thus using them would slow down editing. Using 'hjkl' for movement is great, lots of unix games use the same movement keys too. So I am not sure modeless editors can beat vi in this respect. One last thing: do not force the user to use mouse. Give him the option of using the keyboard too. PS. Did someone mention vi emulation for Emacs? Where can I get it? :-) In fact I was about to write one for Zmacs but changed my mind because my Lisp machine project ended. -------------------------------------------------------------------- Joel Loo Peing Ling composed on Thu Mar 16 10:45:16 CST 1989 -------------------------------------------------------------------- MCC | Email: loo@sw.mcc.com 3500 West Balcones Centre Dr. | Voice: (512)338-3680 (O) Austin, TX 78759 | (512)343-1780 (H)
sawant@nunki.usc.edu (Abhay Sawant) (03/17/89)
In article <79700025@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: > >The things I like about VI are > > -- I used to appreciate its incredible speed. It can maintain > the screen while using VERY FEW cpu cycles. Unfortunately, > this "feature" is rapidly becoming obsolete, with cray-1's > on a chip being introduced every day. I'm sorry; i can't see *any* editor with Unix approaching the speed of writing on screen memory. Believe me, *most* Unix machines i've used so far have problems keeping up with me when writing-invoking editor commands at over 100 wpm. Whatever goes for vi; speed is not one of them.
gaynor@athos.rutgers.edu (Silver) (03/17/89)
> Unfortunately, folding in GNU, as you are referring to it, isn't much use > (unless things have changed drastically in a newer version of GNU Emacs than > I have). You'd be surprised... Unfortunately, (1) all the scanning through lines collapsed under selective-display is frighteningly inefficient, and (2) narrow-to-region, I feel, was improperly implemented. I think it should have been implemented like folds, thus called narrow-away-region, and maintain a tree of narrowings in the buffer. A little self-hype here, I voiced that little opinion in comp.emacs a couple of years ago, but got no responses. > Folding really becomes useful when all the things you have folded are carried > across between edit sessions and when all the 'commands' in the editor really > 'understand' folding. Agreed. Such would have been easily accomplished with my narrow-away-region, the `map-file' would be trivial to read and write. Sniff, sniff. > And since I didn't like the idea of embedding special characters inside of my > source files to 'help out' the editor True enough. I agree, working around the current implementation can be a bitch. > emacs <-> basic...big, slow, but you can do a lot of reprogramming > around the rich command set...note that this is > interpreted tokenized basic, not compiled. > ... > cased <-> C...a higher level (case) editor that allows truly compiled-in > modules and integrates nicely into the environment. This > editor would be both programmable and extensible (i.e you > can not only program based on the current libc.a, but you > can also develop your own low level routines if you need > to). Unfortunately, I still haven't found such an editor. Note that GNU Emacs is a cased editor of its own Lisp extension language. It's only drawback is that it does not compile to native machine code. Regards, [Ag] gaynor@rutgers.edu
caasnsr@nmtsun.nmt.edu (Clifford Adams) (03/18/89)
In article <5552@brspyr1.BRS.Com> miket@brspyr1.BRS.Com (Mike Trout) writes: >: You can use vi all you want, and it may work just fine for you. Fine; that's your business. But you should be aware that while you are putt-putting along in your Sopwith Pup, most of the rest of us have climbed into P-38 Lightnings. You may be very comfortable with the Pup, but the real world has left you behind. First of all, I'm a spoiled GNUmacs user. I like a lot of the features of the editor. But I have my limits. I have recently been working with a HP9000 series 300. Not the fastest machine around. Emacs (Unipress) takes over 60 seconds to load on that machine. I finally got fed up with it and learned the basics of VI. VI takes less than 5 seconds to load on that machine. I got the basics of VI in about 10 minutes, and was reasonably comfortable typing C code in about an hour. I still use Emacs for large/long typing jobs, but for short tasks, or debugging, VI is my choice. I know--I should work with a faster machine. For some reason they won't let me use the Cray for Emacs, however :-). [I'm testing the distribution of this message. If you are in the Mid or Southwestern US and see this message, please mail me a note. Thanks.] -- Clifford A. Adams --- "I understand only inasmuch as I become." caasnsr@nmt.edu ...cmcl2!lanl!unm-la!unmvax!nmtsun!caasnsr (505) 835-6104 | US Mail: Box 2439 Campus Station / Socorro, NM 87801
emoffatt@cognos.uucp (Eric Moffatt) (03/20/89)
In article <743@stag.UUCP> trb@stag.UUCP ( Todd Burkey ) writes: >In article <2112@mister-curious.sw.mcc.com> loo@mister-curious.sw.mcc.com (Joel Loo) writes: >> > >How do other programmers/hackers out there feel about the need for >higher level programming editors/tools? Are you completely happy with >your current editor, so things like folding and inter-file >relationships aren't really of any foreseeable use? Is moded vs. >non-moded really the issue between editors, or is it non-programmable >vs. programmable, or does it simply boil down to the actual options >and commands you have available in an editor? > > -Todd Burkey > trb@stag.UUCP > or ... tburkey@eta.com For my money moded vs. non-moded... is not really an issue. I have used VI, XEDIT, TECO, Apollo and about twenty other text editors over the years. I would LOVE to see some good LANGUAGE SPECIFIC editors !! A friend and I used to spend lunches discussing a C editor which worked on the parse tree and not "TEXT". It really seemed like a good idea, things like "copy IF statement (or FOR, WHILE...)" as well as "rename global var" etc. not to mention checking for proper syntax (on command, I hate it when my terminal BEEPS at me when I'm just power coding :-). Does anyone know of any such editors ?? Text is just the method we use to describe the things we want the machine to do. It's not neccessarily the best way, I would gladly use a "visual Programmer" (if I could find one !!). -- Eric (Pixel Pusher) Moffatt - Cognos Incorporated: 3755 Riverside Drive Voice: (613)738-1440 (Research) FAX: (613)738-0002 P.O. Box 9707 uucp: uunet!mitel!sce!cognos!emoffatt Ottawa, Ontario, arpa/internet: emoffatt%cognos.uucp@uunet.uu.net CANADA K1G 3Z4
jpdres10@usl-pc.usl.edu (Green Eric Lee) (03/21/89)
In article <2112@mister-curious.sw.mcc.com> loo@mister-curious.sw.mcc.com (Joel Loo) writes: >I hope this is not an editor war but honest discussion of pros >and cons of various editors. I have used over a dozen of text >editors/word processors. My comments might be useful to some: >(take note that I came to use vi only recently, it is my LAST and >NOT the first editor.) >natural to him. Use of the mouse is, again, nice for beginners, >but I find it a pain when I was forced to use it in Smalltalk and >Macintosh; I just could not do cutting and pasting as fast as in >vi (nothing to do with my agility, it is inherent with mice, a >lot of hackers will agree with me).] Mice will never replace the keyboard for operations such as, e.g., cut-and-paste. But mice have their place. Anti-mice people might b*tch and groan, but -- pointing at a point, then clicking the mouse button, is a much faster way of getting to that point than repeatedly hitting the cursor keys (for one thing, I always overshoot). And for someone who's not a regular user of a particular text editor, pull-down menus are a godsend. At least, if they're a supplement to keyboard commands, and not a replacement. Want to know what the command is for, say, "delete sentence"? Pull down the "Editing Operations" menu, select the "delete" item, select the "sentence" sub-item which has the "M-^D" keycode abbreviation to tell you how to do it without the menus next time... and it's all just one stroke of the mouse, without all the typing and searching needed for, say, the GNU Emacs help function. (slight note: I am an EXTREMELY fast typer... maybe some people may find themselves slowed by occasionally moving a mouse with their right hand, but I don't see how). >I had use a few text formatters/word processors too. WYSIWYG: >Wordstar, MS word, WordPerfect, PageMaker, FrameMaker. Non- >WYSIWYG and non-interactive ones: TeX and Runoff (DEC). WordPerfect is only slightly WYSIWYG. It mostly combines a normal text editor (somewhat stripped) with a text formatter (somewhat similar to nroff or runoff, with about the same power except when it comes to typesetting capabilities). I have used a true WYSIWYG text editor on a computer with a bit-mapped display, and found it so slow as to be almost unusable (upgrading from 68000 to 68020 might have helped, but who's going to buy a $1K add-on just to run a word processor???). >flexible as TeX or xxxOff; fully WYSIWYG software encourages time >wasting since users do a lot of fine adjustments; most 'WYSIWYG "time wasting"? You sound like the old folks who wouldn't allow people to "waste" computer time by editing on-line when they could do it for "free" by punching up cards before-hand! I haven't seen any studies as to whether WYSIWYG software improves or decreases productivity (and note that productivity can be measured by more than words per minute... if the output looks more polished and professional, that's a form of increased productivity too). >Finally, vi is efficient in a lot of operations, especially those >that we do 80% of the time during an editing session. There are a Perhaps... I really don't know, since I'm not a regular vi user (I use it to occasionally do a quick-and-dirty operation, else I use Emacs, which I learned years before I saw my first Unix machine). But I might note that VI doesn't do a couple of things which I count as necessary. You cannot edit multiple files onscreen at the same time (with the ability to freely move text between them), and you cannot have multiple windows into one file (e.g., one at the top into declarations, one at the bottom into the function you're currently writing). These are not trivial considerations. My current PC is an Amiga. I have been searching for a programming text editor for some time, and have never found one that satisfies me completely. The two considerations above (multiple windows, multiple files) are the most-missed features. The program I use most for "C" code, Matt Dillon's DME editor, does multiple windows (iconifiable to get them out of the way real quick) and is very "C"-friendly, which is why I prefer it over MG Emacs. Still, though, I find myself missing the ability to look at two parts of a file at the same time... especially since I run a 52-line screen, which lets me SEE my text, instead of the common 24-line portholes which get a bit frustrating at times. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // {uunet!dalsqnt,killer}!usl!elg (318)989-9849 | | \X/ >> In Hell you need 4Mb to Multitask << |
gaynor@athos.rutgers.edu (Silver) (03/21/89)
dieter@jupiter.nmt.edu writes: > Overall, though, Emacs is not a WYSIWIG editor. Yes it is, noting that a _text_ editor displays and edits ascii characters. The buffer data and display interpretation are extremely simple: the character symbols of juxtaposed characters in the buffer are displayed juxtaposed in a window, except that any character following a newline is displayed on the next window line and newlines display similarly to a blank or nothing. (Let's assume a window is sufficiently wide to display the longest line, to avoid talking about wrap and such.) Now, if you want to talk about the display interpretation of a raw titty, other word/document processor, or printer, or something, ok. Regards, [Ag] gaynor@rutgers.edu
awm@doc.ic.ac.uk (Aled Morris) (03/21/89)
In article <79700025@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: > Each >time I get a new emacs, I make it emulate the features I'm accustomed >to in the old emacs. This way, I can take advantage of any emacs >without having to learn an entirely new editor. That's my philosophy too, however by the time I've learnt how to program the new Emacs to look like the old, I will have got used to the defaults and won't want to change back! My current editor is GNU Emacs, I like it a lot. It was hard to change from VI (about two years transition), and I still use VI for "quicky" edits (especially on Sun-3/50s), for developing programs, however, GNU can't be beat. I look forward to running an X version on my X terminal (if only...) with multi windows and fonts and...and... Aled Morris systems programmer mail: awm@doc.ic.ac.uk | Department of Computing uucp: ..!ukc!icdoc!awm | Imperial College talk: 01-589-5111x5085 | 180 Queens Gate, London SW7 2BZ
gaynor@athos.rutgers.edu (Silver) (03/22/89)
> I would LOVE to see some good LANGUAGE SPECIFIC editors! There was quite a bit of discussion concerning such in this newsgroup something over year ago. Feel like consulting the archives? By the way, since the discussion, I think someone wrote a package for GNU Emacs to consult an incremental parser for the language you were editing, which supposedly did some interesting things. I never followed it up, but I point you to gnu.emacs and comp.emacs. > Text is just the method we use to describe the things we want the machine to > do. Agreed. In a similar vein, I am a screaming fanatic about defining executable objects of a language as first-order data in the language. I.e., that routines in the language are treated just like other data, and can be inspected, modified, etc. Lisp (functions are lambda expressions, which are lists formatted something like (lambda (arg-1 ... arg-N) body-form-1 ... body-form-M)), PostScript (routines are simply arrays marked executable), Prolog (every dang thing is an assertion, which can be asserted), and a few other languages support this idea. Regards, [Ag] gaynor@rutgers.edu
gaynor@athos.rutgers.edu (Silver) (03/22/89)
Re: my previous message, executable objects as data I got side-tracked, and forgot to catch up with the topic at hand. Now, these languages for the most part have a very simple, orthogonal syntax. This makes it fairly easy to write data editors because you don't have a lot of syntactic fecal matter competing for attention. Regards, [Ag] gaynor@rutgers.edu
aad@stpstn.UUCP (Anthony A. Datri) (03/23/89)
In article <2142@nmtsun.nmt.edu> dieter@jupiter.nmt.edu (The Demented Teddy Bear) writes: >Well, one of my favorite examples is editing executables (yes, I know >string is completely wrong....) You can do this under GNU (and >probably other) Emacs. Seems to work fine under Unipress. Microemacs links to truncate long lines, and I recall that Epsilon likes to insert LF after CR when reading in a file. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, my VT05, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
john@hcr.UUCP (John R. MacMillan) (03/23/89)
In article <Mar.15.13.17.00.1989.4476@athos.rutgers.edu> gaynor@athos.rutgers.edu.UUCP writes: |> Are you completely happy with your current editor, | |Yes, GNU Emacs. Unfortunately, while GNU does do everything I want, it does 10 times as much that I don't want. As such, it's bigger and slower than my "ideal" editor. To pick other nits, I'd rather not have lisp as the macro language, and I'd rather have real windows than split screens. Of course it's as close as I've come, but I'm not yet "completely happy". -- John R. MacMillan Wasn't me she was foolin' 'cause she knew HCR Corporation what she was doin' when she told me how to {utzoo,utcsri}!hcr!john awk this way -- Ahosmith
barnett@crdgw1.crd.ge.com (Bruce Barnett) (03/24/89)
In article <2125@mister-curious.sw.mcc.com>, loo@mister-curious (Joel Loo) writes: >The important auto-indentation feature (for C and Lisp) are lacking in vi. >(Or is there a unix tool to do that?) I am not sure what your exact question is, but you can set autoindent, and when you indent a line, the next line is indented the same level. The next tab indents two levels. There is a key to undent. (My vi is rusty) You can run indent on a portion of a file while in vi. You could also define an electric VI macro, (which I defined to be a function key), that would insert a '{' go to next line insert a '}' go back a line indent one level go into append mode. You could define an electric IF, etc. I just used the auto-indent on the electric '{'. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!steinmetz!barnett, <barnett@steinmetz.ge.com>
toma@tekgvs.LABS.TEK.COM (Tom Almy) (03/24/89)
In article <3088@stpstn.UUCP> aad@stpstn.UUCP (Anthony A. Datri) writes: >[...] and I recall that Epsilon likes to insert LF after CR when reading >in a file. In the interest of accuracy, Epsilon normally strips CRs when reading a file and adds a CR before each LF when writing. But files can be read and written in "image" mode, in which case no translation occurs (and the control-M characters appear on the screen). Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers apply
toma@tekgvs.LABS.TEK.COM (Tom Almy) (03/24/89)
In article <5620@cognos.UUCP> emoffatt@cognos.UUCP (Eric Moffatt) writes: [...] >I would LOVE to see some good LANGUAGE SPECIFIC editors !! A friend and I >used to spend lunches discussing a C editor which worked on the parse tree >and not "TEXT". It really seemed like a good idea, things like "copy IF >statement (or FOR, WHILE...)" as well as "rename global var" etc. not >to mention checking for proper syntax (on command, I hate it when my >terminal BEEPS at me when I'm just power coding :-). Does anyone know of >any such editors ?? Well the Pascal compiler/editor "Alice" does just this. They have a virtually free demo version that would let you try it out. My opinion -- good idea for students learning the language, but a real drag once you know what you are doing. Software Channels Inc (assuming they are still around): (USA) (Canada & international) 4 Kingwood Place 212 King St. W. Kingwood, TX 77339 Toronto M5H 1K5 (713) 359-1024 (416) 591-9131 Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
les@chinet.chi.il.us (Leslie Mikesell) (03/25/89)
In article <25@hcr.UUCP> john@hcrvax.UUCP (John R. MacMillan) writes: >Unfortunately, while GNU does do everything I want, it does 10 times >as much that I don't want. As such, it's bigger and slower than my >"ideal" editor. Has anyone written a Truely Tiny Emacs? I'd like to see something suitable for quick replies to mail and such. One window, one buffer, all text in memory would be fine. However, it should have two moderately complicated features: (1) the ability to parse GNU keymaps for the subset of functions it handles and (2) the ability to exec its big brother on the rare occasions that you need it, preferably with cursor positioning intact. Les Mikesell
bph@buengc.BU.EDU (Blair P. Houghton) (03/25/89)
In article <5620@cognos.UUCP> emoffatt@cognos.UUCP (Eric Moffatt) writes: >In article <743@stag.UUCP> trb@stag.UUCP ( Todd Burkey ) writes: >>In article <2112@mister-curious.sw.mcc.com> loo@mister-curious.sw.mcc.com (Joel Loo) writes: >>> >>How do other programmers/hackers out there feel about the need for >>higher level programming editors/tools? Are you completely happy with >> >used to spend lunches discussing a C editor which worked on the parse tree >and not "TEXT". It really seemed like a good idea, things like "copy IF >statement (or FOR, WHILE...)" as well as "rename global var" etc. not > >Text is just the method we use to describe the things we want the machine >to do. It's not neccessarily the best way, I would gladly use a "visual >Programmer" (if I could find one !!). Lemme look.... Here it is. Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Envirionments (last November in Boston, well, Cambridge, actually.) Nertz. Well. There's a lot of stuff in the proceedings about environments and some object-oriented visualization software, but not the one I wanted. I remember at least one of the demonstrations was of a product being built by a british company that iconifies the whole process. You use the mouse to pick and place functional elements (decision-diamond, output-dingus, control-flow-arrow, that sort of thing) as though you were editing the flow diagram, then you put the mouse in one of the blocks and type a few statements or expressions to finish defining its meaning. It means essentially that you don't have to think in terms of a broad, swooping flow structure and then cut and paste it into a vertical strip of code; you can put a spaghetti of arrows and blocks all over the window and the software will take care of the coding. It seems to do for high-level languages what high-level languages did for assembly, and assembly for machine-level coding... I can't remember the name of the company, and I think I've lost their brochures. Sorry. They were heavily geared towards ADA, anyway. They all were. That's where the easy, no-real-strings-attached money is going to in the military-industrial-software-simplex these days. --Blair "Simpletonex, you mean..."
night@pawl.rpi.edu (Trip Martin) (03/26/89)
In article <237@usl-pc.usl.edu> jpdres10@usl-pc.UUCP (Green Eric Lee) writes: >Mice will never replace the keyboard for operations such as, e.g., >cut-and-paste. But mice have their place. Anti-mice people might b*tch >and groan, but -- pointing at a point, then clicking the mouse button, >is a much faster way of getting to that point than repeatedly hitting >the cursor keys (for one thing, I always overshoot). I would say the opposite is true, at least for me. Moving the cursor using the keyboard doesn't have to be done one character at a time, per keystroke. Both emacs and vi, and any decent text editor for that matter allow you to the cursor around in any number of ways. As for why the mouse is slower, I have to look at my hands when moving to or from the mouse. Moving my attention away from the screen like that slows me down. I also tend to overshoot with the mouse. It does take a fair amount of dexterity to really become quick at using a mouse. I suspect quite a few people have the same problems I do with mice. > And for someone who's not a regular user of a particular text >editor, pull-down menus are a godsend. At least, if they're a >supplement to keyboard commands, and not a replacement. Want to know >what the command is for, say, "delete sentence"? Pull down the >"Editing Operations" menu, select the "delete" item, select the >"sentence" sub-item which has the "M-^D" keycode abbreviation to tell >you how to do it without the menus next time... and it's all just one >stroke of the mouse, without all the typing and searching needed for, >say, the GNU Emacs help function. True, menus of any kind are a help when using a new text editor. However, if I were going to learn a new editor, I'd rather have a reference card around so I can learn the keyboard commands, and not the menus. > (slight note: I am an EXTREMELY fast typer... maybe some people >may find themselves slowed by occasionally moving a mouse with their >right hand, but I don't see how). It seems to me that you probably have the dexterity to use a mouse to its fullest. Other people like myself are not so lucky. I'm a moderately fast typer, but my dexterity isn't all that great. Trip Martin night@pawl.rpi.edu night@uruguay.acm.rpi.edu
barnett@crdgw1.crd.ge.com (Bruce Barnett) (03/27/89)
In article <990@rpi.edu>, night@pawl (Trip Martin) writes: >As for why the mouse is slower, I have to look at my hands when moving >to or from the mouse. Moving my attention away from the screen like >that slows me down. I also tend to overshoot with the mouse. It does >take a fair amount of dexterity to really become quick at using a mouse. >I suspect quite a few people have the same problems I do with mice. It doesn't really take dexterity, just practice. Just like a keyboard takes practice. I have never taken a lesson, but I do okay. Same with a mouse. For instance, if I have to move the cursor more than 20 lines, and to a different column, the mouse is the easiest way to do it. Especially when the sizes of the windows are always different heights, etc. >It seems to me that you probably have the dexterity to use a mouse >to its fullest. Other people like myself are not so lucky. I'm a >moderately fast typer, but my dexterity isn't all that great. Last I knew, Trip, you didn't have a workstation in front of you 8 hours a day. If you did, and you made the effort, you would develop the 'dexterity' you desire. Most mouse systems I am aware of are tunable, so you can set scaling factors (The faster you more, the farther the mouse travels.) The default might be uncomfortable for a novice, and may in fact be set for a intermediate user. I think the problem with most people is that they are so set on their ways that they had a hard time learning to use different tools. As an example, the people who wrote the mouse based front ends for GNUemacs (NeWS and SunView), don't really understand the secondary selection mechanism, because they don't use mice much. Textedit has a better mouse interface than does gnuemacs, which is a shame. I like emacs's power, and textedit's mouse interface. It really bugs me that I can exchange two pieces of text in any two windows by just pressing and releasing three keys on the keyboard, *except* when I am using emacs or vi. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!steinmetz!barnett, <barnett@steinmetz.ge.com>
gregg@ihlpb.ATT.COM (Wonderly) (03/27/89)
From article <237@usl-pc.usl.edu>, by jpdres10@usl-pc.usl.edu (Green Eric Lee): > ... > > But I might > note that VI doesn't do a couple of things which I count as necessary. > You cannot edit multiple files onscreen at the same time (with the > ability to freely move text between them), and you cannot have > multiple windows into one file (e.g., one at the top into > declarations, one at the bottom into the function you're currently > writing). While this is handy and I will not attempt to dispute the merits of multiple windows on the screen, I will say this. Moving text between two files is easy using the named buffers. Just use "[a-z]<some yank or delete command> followed by :vi file to switch to the other file. Then use "[a-z][pP] to place the text where you want it (note that a delete sequence automatically inserts text into a numbered buffer which is also available after switching files). When you want to go back to the other file use ^^ or ^. or :vi # if your terminal won't send either of those sequences. If you place the opening brace of the function at the beginning of the line you can use [[ to move to the top of the function, do your declarations and then use '' to move back to your old place. My opinion is that as long as xMACS editors continue to use a language such as lisp for programability there will continue to be resistance. Every version I have tried to implement vi's % operator in has failed miserably in speed. If you really want to see a fast programable editor get someone to show you DEC's TPU for VMS. If you want to see how I would like to see VI, look at my VI emulation in TPU (select regions, multiple windows and buffers etc). -- Gregg Wonderly DOMAIN: gregg@ihlpb.att.com AT&T Bell Laboratories UUCP: att!ihlpb!gregg
sommar@enea.se (Erland Sommarskog) (03/28/89)
Gregg Wonderly (gregg@ihlpb.ATT.COM) writes: >My opinion is that as long as xMACS editors continue to use a language >such as lisp for programability there will continue to be resistance. >Every version I have tried to implement vi's % operator in has failed >miserably in speed. > >If you really want to see a fast programable editor get someone to show >you DEC's TPU for VMS. If you want to see how I would like to see VI, >look at my VI emulation in TPU (select regions, multiple windows and >buffers etc). Hear, hear! Just couldn't agree more. Emacs may have cool functionality, but I doubt to call it a serious editor, after all the times I just waited for it to echo a typed character. Now, TPU, that is a serious editor. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se I used to say "It could have been worse, it could have been Pepsi", then I drank a Diet Coke...
d87-hho@nada.kth.se (Henrik Holmstr|m) (03/28/89)
I like Emacs (GNU). Some other people don't. They like vi. Or XEdit. Or TPU. Or cat. Or something else. But who cares? Those of you who must go on, can't you do that in talk.bizarre or comp.editors?
fischer@iesd.dk (Lars P. Fischer) (03/28/89)
In article <4392@enea.se> sommar@enea.se (Erland Sommarskog) writes: > >My opinion is that as long as xMACS editors continue to use a language > >such as lisp for programability there will continue to be resistance. >Hear, hear! Just couldn't agree more. Emacs may have cool >functionality, but I doubt to call it a serious editor, >after all the times I just waited for it to echo a typed >character. Now, TPU, that is a serious editor. It's not UNIX that needs a "real" editor. Programmers simply need real computers, not some flunky old vaxens. Emacs is all the editor I need. And fast, too. /Lars -- Lars Fischer, fischer@iesd.dk, {...}!mcvax!iesd!fischer Dept. of Math. and Comp. Sci., University of Aalborg Strandvejen 19, DK-9000 Aalborg, DENMARK Any suffiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke
neubauer@bsu-cs.UUCP (Paul Neubauer) (03/28/89)
In article <4392@enea.se> sommar@enea.se (Erland Sommarskog) writes: >Gregg Wonderly (gregg@ihlpb.ATT.COM) writes: (edited considerably--pn) > >My opinion ... xMACS ... lisp ... failed miserably in speed. > >... fast programable editor ... DEC's TPU for VMS. > >Hear, hear! Just couldn't agree more. Emacs may have cool >functionality, but I doubt to call it a serious editor, >after all the times I just waited for it to echo a typed >character. Now, TPU, that is a serious editor. I don't want to throw too much cold water on anyone. I happen to like both, and have written several thousand lines of TPU myself. I just think that we need to keep in mind what environments we are dealing with. Here (Ball St. U.) we have a cluster of 3 11/785's and 1 8650 with far too many users. Waiting for EVE to echo a character can be just as frustrating as waiting for GNUemacs on the 785 running BSD4.3 that I am writing this on. (Though actually I am using JOVE right now.) If you want responsiveness, there is virtually no alternative to having a system dedicated to you, whether that is a personal microcomputer or a very lightly loaded VAX or whatever other lightly loaded system. -- Paul Neubauer neubauer@bsu-cs.bsu.edu neubauer@bsu-cs.UUCP <backbones>!{iuvax,pur-ee}!bsu-cs!neubauer
zifrony@TAURUS.BITNET (03/29/89)
In article <743@stag.UUCP>, trb@stag.BITNET writes: > ... My idea of an ideal editor is one that 1) allows > multi-file editing with a clean and fast buffering scheme, 2) fully > supports folding, 3) allows the programmer to relate lines and words > and use these relationships in a hyper-text like manner (i.e. moving > back and forth between a program document and the appropriate lines > of code at the press of a few keys), 4) has configurations save and > restore modes (so you can get back to EXACTLY the same place you left > off editing the day before...with all buffer info intact), and 5) has > more intelligence built in (rather than interpreted in macros.
zifrony@TAURUS.BITNET (03/29/89)
Sorry, this is a repost to the request of some people which didn't get it in its entirety. In article <743@stag.UUCP>, trb@stag.BITNET writes: > ... My idea of an ideal editor is one that 1) allows > multi-file editing with a clean and fast buffering scheme, 2) fully > supports folding, 3) allows the programmer to relate lines and words > and use these relationships in a hyper-text like manner (i.e. moving > back and forth between a program document and the appropriate lines > of code at the press of a few keys), 4) has configurations save and > restore modes (so you can get back to EXACTLY the same place you left > off editing the day before...with all buffer info intact), and 5) has > more intelligence built in (rather than interpreted in macros.
zifrony@TAURUS.BITNET (03/29/89)
In article <743@stag.UUCP>, trb@stag.BITNET writes: > ... My idea of an ideal editor is one that 1) allows > multi-file editing with a clean and fast buffering scheme, 2) fully > supports folding, 3) allows the programmer to relate lines and words > and use these relationships in a hyper-text like manner (i.e. moving > back and forth between a program document and the appropriate lines > of code at the press of a few keys), 4) has configurations save and > restore modes (so you can get back to EXACTLY the same place you left > off editing the day before...with all buffer info intact), and 5) has > more intelligence built in (rather than interpreted in macros. > > ... (Deleted stuff) > > -Todd Burkey > trb@stag.UUCP > or ... tburkey@eta.com In addition, I think that there is a need for the following features, which can make life much better for the editor's users: 1. A two window option, like in DEC's EVE, to better utilize the multi-file editing capability. 2. A recovery mechanism after a crash is more than welcome. If editable, like the editing journal in DEC's environment, it could be used to suppress a few bad commands entered mistakingly during the editing session. I must state that vi supports a recovery after crash mechanism as well. 3. Have the result of a pushed system command (like :!<cmd> or EVE's DCL command) be put in a new editing buffer, so it can be looked at, and incorporated in the files being edited. Unfortunately, vi does not support these features in a satisfying way; alas, no better alternative is available in the standard UnIX environment. (I know of GNU Emacs, but I don't think it is supplied with each UnIX system, and it is worse to learn than vi, and requires a lot of time investment to be utilized in a good way). Working with a SUN workstation, I find TEXTEDIT, the mouse-based editor, and the possibility to have a few copies of it concurrently, as a compensation for the lack of nice features. This editor is operated very quickly, and apart of the unavailability of a native "operate a command on all the file", it is very convenient (I have vi to do major replacements). Doron Zifrony zifrony%Taurus.bitnet@Cunyvm.cuny.edu or Msc. Student zifrony@Math.Tau.Ac.IL Tel Aviv Univ. Israel
gaynor@athos.rutgers.edu (Silver) (03/29/89)
(Doron, your message made it through this time!) >> = trb@stag.bitnet > = zifrony@taurus.bitnet >> 1) allows multi-file editing with a clean and fast buffering scheme Got it. >> 2) fully supports folding Got it. >> 3) allows the programmer to relate lines and words and use these >> relationships in a hyper-text like manner (i.e. moving back and forth >> between a program document and the appropriate lines of code at the press >> of a few keys) Doesn't sound to difficult to program this in... An extended tags mechanism would probably suffice to start. >> 4) has configurations save and restore modes (so you can get back to EXACTLY >> the same place you left off editing the day before...with all buffer info >> intact) Got it. >> 5) has more intelligence built in (rather than interpreted in macros) This is rather vague. I tend to say "Got it." simply because the extension language is much more than a dumb macro language. > In addition, ... > 1. A two window option, like in DEC's EVE, to better utilize the multi-file > editing capability. Got it. > 2. A recovery mechanism after a crash is more than welcome. Got it, normally via n-keypress-checkpointing (you set n) and automatic backup version generation. > If editable, like the editing journal in DEC's environment Journaling as you describe would be trivial to implement. Most find the recovery mechanisms adequate, though. > suppress a few bad commands Brings to mind the feature which allows one to arbitrarily restrict functions known to be confusing, a command-disabling mechanism. > 3. Have the result of a pushed system command ... be put in a new editing > buffer, so it can be looked at, and incorporated in the files being > edited. Got it, several different ways. > (I know of GNU Emacs, but I don't think it is supplied with each UnIX system, > and it is worse to learn than vi, and requires a lot of time investment to be > utilized in a good way). First, note that Emacs is persistent. If it's not supplied with a given Unix system, forgive the vendor's ignorance, and install it yourself. Ports to most machines can be made without hitch through the supplied machine and os definitions. comp.emacs and gnu.emacs can be consulted when difficulties arise. (Emacs users provide suprisingly good support to each other.) It is no worse to learn than vi. Better in some respects, mostly because it is the best-documented individual software product that I can think of (note that _all_ of the documentation is on-line, most of it interactively accessable). It boils down to "you get what you pay for". You invest a little time into either, you get only a novice understanding. You invest quite a bit more time into either, you get an expert understanding. That's as far as you go in vi. In Emacs, you keep on going, learning neat time-saving feature after neat feature, as long as you have the time and will to do so. Or you can continue at a lower level, and learn to program new tricks into the old dog. The environment Emacs provides for its own extension language is pretty nice - I do most of my non-C programming in Emacs Lisp, just for the nice environment, smokin' user interface, and wonderful system interface. For starting emacs users, my advice is simple: run through the interactive tutorial (takes about 2 hours) to acquire a basic working knowledge. Then, make a print of the 3-page reference `card', and _use_ it. Then, when comfortable, browse the Info tree for detailed information on more advanced features (the Info tree is a tree-menu-based interctive browser for the several-hundred-page detailed user manual). > Working with a SUN workstation, I find TEXTEDIT, the mouse-based editor, and > the possibility to have a few copies of it concurrently, as a compensation > for the lack of nice features. Got the mouse support under X and NeWS. (I haven't used suntools in over a year, but even so, never used or looked at emacstool.) Regards, [Ag] gaynor@rutgers.edu
jpdres10@usl-pc.usl.edu (Green Eric Lee) (04/01/89)
In article <4392@enea.se> sommar@enea.se (Erland Sommarskog) writes: >Gregg Wonderly (gregg@ihlpb.ATT.COM) writes: > >My opinion is that as long as xMACS editors continue to use a language > >such as lisp for programability there will continue to be resistance. > >Every version I have tried to implement vi's % operator in has failed > >miserably in speed. >Hear, hear! Just couldn't agree more. Emacs may have cool >functionality, but I doubt to call it a serious editor, >after all the times I just waited for it to echo a typed >character. Now, TPU, that is a serious editor. >Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se You wait for Emacs to echo a typed character? The only time I've waited for GNU Emacs to echo a typed character is when the machine is seriously overloaded (e.g. a dozen Prolog and Lisp hackers merrily doing their thing). I have noticed that GNU Emac's redisplay algorithm is about as efficient as an "intelligent" algorithm can get -- its response time is even faster than the MicroEmacs editors that I've seen (which certainly don't have the excuse of being "big" to account for their speed). Even under load. Of course, I can only vouch for GNU Emacs under Unix (BSD4.x Pyramids here, high end 3b2 running Sys V.3 elsewhere). I suspect it would be far less efficient under VMS, because it was originally designed to run under Unix and was sort of hacked, kludged, and shoe-horned in order to run under VMS. As for Emacs Lisp: Lisp is a naturally interpretive language of far greater power than the usual limited Teco-style extension language. The speed problems come from the fact that it HAS to be interpreted, even if you tokenize it into byte-codes -- Emacs runs on dozens of different machines, with dozens of word organizations and machine languages. If you have an extension language for an editor which was designed for one single machine, and will only run on that one single machine, naturally you can make it run more efficiently than a generalized solution -- at least, on that one single machine. Compiled Lisp has come close to matching Fortran for speed (see Multics MacLisp for an old example). But compilation simply isn't feasible when you're trying for a generalized solution that runs on dozens of different machines. I suggest that if your Emacs staggers and stutters, that you suggest to your management that your company/university/etc. aquire adequate resources for the pursuit of your mission. It's not Emac's fault that you are trying to run it on seriously overloaded equipment, or under an operating system for which it was not designed. If your equipment is too overloaded to run Emacs, it's probably too overloaded for efficient program development and research, too. I have struggled on without adequate equipment when necessary, but it generally takes two to four times longer to develop a program than when you have adequate resources available. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // {uunet!dalsqnt,killer}!usl!elg (318)989-9849 | | \X/ >> In Hell you need 4Mb to Multitask << |
gaynor@athos.rutgers.edu (Silver) (04/02/89)
>>> = gregg@ihlpb.att.com >> = sommar@enea.se (??) > = jpdres10@usl-pc.usl.edu >>> [Lisp is too slow for an extension language.] Not at all, if it's compiled. Now, the target machine for the code is the issue. GNU Emacs interprets its own compiled code in software, so, although it's _much_ faster than interpreting straight lisp, it's still slow compared to native machine code. It would be nice to compile to that level, but this is a tall order, and limits portability. >>> Every version I have tried to implement vi's % operator in has failed >>> miserably in speed. I assumed that this is after you compiled the code. Lemme check this out... You mean % as in "Move the cursor to the matching parenthesis or brace."? (I had to go to the Sun 4.0 Distribution manuals for that - how do you access vi's interactive help? I also couldn't find any documentation in the `official places', which indicates how popular it is at RU.) This is how it's implemented in .../emacs/lisp/lisp.el: ;; Copyright (C) 1985, 1987, 1988 Richard M. Stallman (defun forward-sexp (&optional arg) "Move forward across one balanced expression. With argument, do this that many times." (interactive "p") (or arg (setq arg 1)) (goto-char (or (scan-sexps (point) arg) (buffer-end arg))) (if (< arg 0) (backward-prefix-chars))) The workhorse is scan-sexps, which is a primitive function, so it boogies. >> Emacs may have cool functionality, ... ^^^ That's "does". :^) >> ... but I doubt to call it a serious editor, after all the times I just >> waited for it to echo a typed character. This is ridiculous. I often run GNU Emacs on a decrepit diskless sun2 (4mb ram, ugh) under either X or suntools, running Big Programs and switching between windows often (swap swap swap), and rarely have to wait (except for the occasional swap). Your hardware situation is a nightmare, no? >> Now, TPU, that is a serious editor. I don't know anything about it, so cannot make any judgements beyond the fact that I haven't heard enough about it to know anything about it, and I follow the editing scene to some slight degree. Knowutimean, Vern? > I have noticed that GNU Emac's redisplay algorithm is about as efficient as > an "intelligent" algorithm can get ... It's fascinating to watch the tricks of the redisplay on a slow, smooth-scrolling terminal which emacs has been cruelly fooled into thinking is a fast terminal. The algorithms make the trade-off between compute time vs. screen display time, giving optimal redisplay at the expense of machine cycles. Note that the amount of redisplay work done can be seriously cut down by using `dumber' terminal definitions, and so performing on the display level of the smaller editors. Regards, [Ag] gaynor@rutgers.edu
gregg@ihlpb.ATT.COM (Wonderly) (04/03/89)
From article <248@usl-pc.usl.edu>, by jpdres10@usl-pc.usl.edu (Green Eric Lee): ...stuff about EMACS speed deleted > > As for Emacs Lisp: Lisp is a naturally interpretive language of far > greater power than the usual limited Teco-style extension language. > The speed problems come from the fact that it HAS to be interpreted, > even if you tokenize it into byte-codes -- Emacs runs on dozens of > different machines, with dozens of word organizations and machine > languages. The point I was trying to make is that LISP is not a common language base for most people. A more procedural language such as TPU looks and feels more comfortable. E.g. something like the following is infinitely easier for me to read than lisp. PROCEDURE split_window LOCAL newwin1, newwin2, wintop, slop, winlen; winlen := GET_INFO (CURRENT_WINDOW, "VISIBLE_LENGTH"); IF (winlen < 3) THEN MESSAGE ("Current window too small to split"); RETURN; ENDIF; wintop := GET_INFO (CURRENT_WINDOW, "VISIBLE_TOP"); slop := winlen - ((winlen / 2) * 2); ! subtract 1 from length for status line. newwin1 := CREATE_WINDOW (wintop, (winlen / 2) - 1, ...); newwin2 := CREATE_WINDOW (wintop + (winlen / 2), (winlen / 2) - 1 + slop, ...); ! Map both windows to the current buffer. MAP (newwin1, CURRENT_BUFFER); MAP (newwin2, CURRENT_BUFFER); ! Delete the old window. DELETE (CURRENT_WINDOW); POSITION (newwin1); ENDPROCEDURE; And the compilation of this, or any other interpretive language, can compact a lot of the expressions because we know how to do these things, whereas I don't know of anybody (I have not looked) applying any optimization or other speed ups to lisp based interpreters. Given the difference in speed (I know how DEC did this, the interpreter is a giant VAX case instruction) I would say that the EMACS I used on the same VAX as TPU was not very efficient. -- Gregg Wonderly DOMAIN: gregg@ihlpb.att.com AT&T Bell Laboratories UUCP: att!ihlpb!gregg
flee@shire.cs.psu.edu (Felix Lee) (04/03/89)
In article <Apr.2.04.28.07.1989.3092@athos.rutgers.edu>, gaynor@athos.rutgers.edu (Silver) writes: >>> = sommar@enea.se (??) [...] >>> Now, TPU, that is a serious editor. >I don't know anything about it, so cannot make any judgements TPU only runs on an obscure operating system known as VMS :-) The only reason I've ever heard of TPU is that it was "Exotic Language of the Month" in some issue of _Computer Languages_. It looked pretty reasonable... -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
gaynor@porthos.rutgers.edu (Silver) (04/03/89)
> The point I was trying to make is that LISP is not a common language base for > most people. A most unfortunate circumstance. > [TPU program for split window] I'm convinced, TPU's language _is_ moderately powerful. Got a reference sheet on the language? Post it, and let's pick at it for a bit. > ... optimization or other speed ups to lisp based interpreters. Well, no, not really, you get a much bigger payoff optimizing the compiler output (and the interpreting `machine', if implemented in software). Regards, [Ag] gaynor@rutgers.edu
nate@hobbes.intel.com (Nate Hess) (04/04/89)
In article <10099@ihlpb.ATT.COM>, gregg@ihlpb (Wonderly) writes: > >The point I was trying to make is that LISP is not a common language base for >most people. A more procedural language such as TPU looks and feels more >comfortable. E.g. something like the following is infinitely easier for me to >read than lisp. [TPU example deleted.] Hmmm. Easier for *you*, yes, not easier for me. I think that lisp is an excellent choice as an editor's "native: language. It's a big win to have the language that you write your editor init file with be the same language that you type to the editor's command interpreter. If you're in TPU, looking at a buffer containing the TPU code you defined in your example, how easy is it to change the buffer, and then instantly re-evaluate the definition, so that the modified procedure is now available in your editing session? >Given the difference in speed (I know how DEC did this, the interpreter >is a giant VAX case instruction) I would say that the EMACS I used on >the same VAX as TPU was not very efficient. This might very well be the case. TPU is, however, infinitely inefficient on VAXen running, say, Ultrix(tm, no doubt). It has been optimized to run on VAXen under VMS. Emacs, on the other hand, will run on VAX under VMS, 4.3BSD, Ultrix, etc., etc. In fact, I've taken 200 line .emacs files under Ultrix, transferred them to VMS, and had the exact same functionality (minus VMS BD'ed-ness) as on Ultrix. Porting my Emacs environment to my Sun 386i was as simple as rcp'ing my .emacs file. I would also be willing to bet that, if RMS had the motivation, he could port Emacs over to VMS and optimize it so that it *would* run faster than TPU. Ie., the speed difference is because of portability concerns, not because of the inherent Lispyness of Emacs. Happy editing! --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes woodstock@hobbes.intel.com ...!{decwrl|hplabs!oliveb}!intelca!mipos3!nate
gregg@ihlpb.ATT.COM (Wonderly) (04/05/89)
From article <Apr.3.08.37.22.1989.6904@porthos.rutgers.edu>, by gaynor@porthos.rutgers.edu (Silver): > I'm convinced, TPU's language _is_ moderately powerful. Got a reference sheet > on the language? Post it, and let's pick at it for a bit. TPU is not a simple language. Nor is it small in specification. I can elaborate a little. TPU variables inherit type information from assignment. The types supported are INTEGER, KEYWORD, STRING, PATTERN, MARKER, RANGE, BUFFER, WINDOW, PROGRAM and ARRAY. A MARKER holds a location. A RANGE is the region between two markers as created in rnge := CREATE_RANGE (mark1, mark2, NONE); The NONE KEYWORD can be replaced with BOLD, BLINK, REVERSE or DIM to cause the range to have that video attribute on the screen. A PROGRAM is something returned by COMPILE which can be passed to EXECUTE to do whatever was programmed in the compiled object e.g. Read keystrokes and execute the 'programs' mapped to them, where key_info() is a procedure that uses the currently active keymap to retrieve the desired info. LOOP key := READ_KEY; prog := key_info (key, PROGRAM); IF prog <> 0 THEN EXECUTE (prog); ELSE MESSAGE ("Undefined key"); ENDIF; ENDLOOP; The rest of the types should be obvious. WINDOWS may or may not have status bars. You compose the text that goes into them. The builtin procedure COPY_TEXT is used to move text between BUFFERS and different locations in the same buffer. The DELETE() builtin removes the object that you pass it. It knows how to handle BUFFERS, WINDOWS, MARKERS and RANGES. The ERASE_CHARACTER() builtin erases the number of characters specified in the specified direction. A simple mapping for the DELETE key would be DEFINE_KEY ("ERASE_CHARACTER (-1)", DEL_KEY, "delete key"); which would cause the DELETE key to erase the character behind the current position in the current buffer. There are other things that you would probably wish to do such as guard against the "Can't move beyond beginning of buffer" MESSAGE that would be spit out whenever you are at the beginning of the buffer and type DELETE. DEFINE_KEY accepts a fourth parameter which optionally specifies a keymap that the key is to be defined in. You must use CREATE_KEYMAP and CREATE_KEYMAP_LIST to establish all of the appropriate resources to store the keymaps. My VI emulator uses 3 keymaps. One for command mode, one for insert/edit mode and one that maps all of the keys to a movement routine for the d, c, <, > and y commands to use. I could go on... -- Gregg Wonderly DOMAIN: gregg@ihlpb.att.com AT&T Bell Laboratories UUCP: att!ihlpb!gregg