brendan@cs.widener.edu (Brendan Kehoe) (03/19/91)
I'm working on a "free" version of vi. It's to fully emulate the
current Berkeley-derived versions. After that, it's prettymuch a
free-for-all.
So .. what would you have added to vi, if you could? What would you
have made an option? What would you change?
Please respond via email.
Brendan
--
Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
Widener University in Chester, PA A Bloody Sun-Dec War Zonemrd@ecs.soton.ac.uk (Mark Dobie) (03/19/91)
In <1991Mar18.195343.665@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: > I'm working on a "free" version of vi. It's to fully emulate the >current Berkeley-derived versions. After that, it's prettymuch a >free-for-all. > So .. what would you have added to vi, if you could? What would you >have made an option? What would you change? Well, judging by what crops up in this group repeatedly you couldn't go far wrong in providing, 1) A built in way of justifying text. 2) A more flexible way of editing several files and transferring between them. This could be as simple as a command to go to the previous file (this is provided in many ports) or maybe to select one from the list (:args style). Also, how about preserving the cut buffer between files? ... and the remembering the cursor position in the files too. Mark.
tjc@ecs.soton.ac.uk (Tim Chown) (03/19/91)
In <7214@ecs.soton.ac.uk> mrd@ecs.soton.ac.uk (Mark Dobie) writes: >In <1991Mar18.195343.665@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: >> I'm working on a "free" version of vi. It's to fully emulate the >>current Berkeley-derived versions. After that, it's prettymuch a >>free-for-all. >> So .. what would you have added to vi, if you could? What would you >>have made an option? What would you change? >Well, judging by what crops up in this group repeatedly you couldn't >go far wrong in providing, >1) A built in way of justifying text. >2) A more flexible way of editing several files and transferring > between them. Yes please. And the ability to edit on columns rather than rows would be useful in some circumstances. Tim
tchrist@convex.COM (Tom Christiansen) (03/21/91)
Here's my list. I already sent it in email:
multiple windows.
no limits on line length, etc.
infinite undo buffer.
no more "can't yank/put in global/macro" errors.
editable commands lines with history and completion.
visible marks.
set wrapscan that worked on absolute numbesr not just relative ones.
tilde as a range command "~E".
column mode
8 bit files.
that should be enough to think about.
--tomboykin@encore.com (Joseph Boykin) (03/21/91)
In article <7214@ecs.soton.ac.uk>, mrd@ecs.soton.ac.uk (Mark Dobie) writes: |> In <1991Mar18.195343.665@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: |> Also, how about preserving the cut |> buffer between files? Vi already does this. If you yank or delete something, you put it into a named buffer. For example, to delete a paragraph do "ad} then go to another file, and yank buffer a with "ap. jb
bhoughto@pima.intel.com (Blair P. Houghton) (03/21/91)
In article <1991Mar20.203643.26406@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >Here's my list. I already sent it in email: > visible marks. You can leave that out just fine. No blinky- reversed box thingies for me, thanks. > tilde as a range command "~E". What's wrong with the current default action of ~ ? I rarely use it for anything other than toggling the capitalization when I paste/delete at the beginning of a sentence. --Blair "But when I need speed I :map v ~~~"
ldstern@rodan.acs.syr.edu (Larry Stern) (03/21/91)
>>In <1991Mar18.195343.665@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: > >>> I'm working on a "free" version of vi. It's to fully emulate the >>>current Berkeley-derived versions. After that, it's prettymuch a >>>free-for-all. >>> So .. what would you have added to vi, if you could? What would you >>>have made an option? What would you change? > (some text deleted....) >>Well, judging by what crops up in this group repeatedly you couldn't >>go far wrong in providing, > >>1) A built in way of justifying text. >>2) A more flexible way of editing several files and transferring >> between them. > >Yes please. And the ability to edit on columns rather than rows >would be useful in some circumstances. > I'm not sure if you already plan this but some form of on-line help (such as the F1 key in Sidekick, etc.) would be very helpful IMHO. Larry
wwm@pmsmam.uucp (Bill Meahan) (03/21/91)
And I'd add mouse-based cursor-insertion and range selection (ala' Microsoft Word/Write [Mac]) but NOT requiring X. For example, my 3B1 supports a mouse through its TAM (Terminal Access Method) library which is really an extended version of CURSES. -- Bill Meahan |Product Design & Testing Section Production Test Engineer |Starter Motor Engineering wwm@pmsmam | +1 313 484 9320
wagner@iti.org (Larry Wagner) (03/21/91)
boykin@encore.com (Joseph Boykin) writes: >In article <7214@ecs.soton.ac.uk>, mrd@ecs.soton.ac.uk (Mark Dobie) writes: >|> In <1991Mar18.195343.665@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: >|> Also, how about preserving the cut >|> buffer between files? >Vi already does this. If you yank or delete something, you put it >into a named buffer. For example, to delete a paragraph do "ad} >then go to another file, and yank buffer a with "ap. Yes, but it sure is nice not to even have to use a named buffer. The MKS DOS version of vi allows this and it sure is aggravating not to have that capability on my UNIX machine also. -------------------------------------------------------------------------------- Larry E. Wagner | wagner@chepil.weru.ksu.edu USDA-ARS Wind Erosion Research Unit | wagner@matt.ksu.ksu.edu 105B East Waters Hall, KSU | ...!{rutgers,texbell}!ksuvax1!weru!wagner Manhattan, KS 66506 |phone (913)532-6807 -------------------------------------------------------------------------------- -- -------------------------------------------------------------------------------- Larry E. Wagner | wagner@chepil.weru.ksu.edu USDA-ARS Wind Erosion Research Unit | wagner@matt.ksu.ksu.edu 105B East Waters Hall, KSU | ...!{rutgers,texbell}!ksuvax1!weru!wagner Manhattan, KS 66506 |phone (913)532-6807 --------------------------------------------------------------------------------
gast@maui.cs.ucla.edu (David Gast) (03/21/91)
In article <7220@ecs.soton.ac.uk> tjc@ecs.soton.ac.uk (Tim Chown) writes: >In <7214@ecs.soton.ac.uk> mrd@ecs.soton.ac.uk (Mark Dobie) writes: >>In <1991Mar18.195343.665@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: >>> I'm working on a "free" version of vi. It's to fully emulate the >>>current Berkeley-derived versions. After that, it's prettymuch a >>>free-for-all. >>> So .. what would you have added to vi, if you could? What would you >>>have made an option? What would you change? >>1) A built in way of justifying text. I hope you mean a program like fmt, not one like nroff. It is very difficult to read right justified text with a fixed width font. Anyway, since fmt is freely available, I would just package it with your program and leave it out of the editor. >>2) A more flexible way of editing several files and transferring >> between them. More than one window on a file would be nice too. Here are some more ideas. In some cases, I recognize that they can be done now, but in an inconvenient manner. 1. All bugs fixed. 2. A macro language that easily allows constructs like if, then, else, fi, read from the keyboard, etc. Also, a way to easily query and find out the line number, the word number, the character number, total lines, etc. A user map should not affect the meaning of another character. No "too dangerous to map that" messages. 3. The ability to have something like ^W indicate the word under the cursor. Macros become more complex if you have to consider the position in the word. For example, if the cursor is one the first letter in the word, then b goes to the first letter of the previous of the word. If it is on the second or greater letter in word, it goes to the beginning of the word. ^W or its equivalent would allow you to say, this word, no matter where the cursor is. I realize there are problems because there are words and WORDs and you may want to go to the beginning or the end. 4. Allow Meta-keys to be used. 5. Display lines of arbitrary length. 6. Handle Null characters and characters greater than 127. 7. The ability to make use of terminal characteristics like underline, or bold when operating on lines in a file. For example, perhaps I would like to reverse video all lines beginning with Subject: . 8. The ability to stack or at least toggle set options. 9. N should take counts; ~ should be treated like any other object. A. Should not ``always'' go to the beginning of a line or place the line in the middle of the screen. (Particularly after u). B. Ability to save/recall patterns. (I know about @). Well, that should be enough ideas for the moment. I am sure that I have other minor annoyances. David Gast
rouben@math13.math.umbc.edu (Rouben Rostamian) (03/21/91)
>In <1991Mar18.195343.665@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: > I'm working on a "free" version of vi. It's to fully emulate the >current Berkeley-derived versions. After that, it's prettymuch a >free-for-all. > So .. what would you have added to vi, if you could? What would you >have made an option? What would you change? Here's my two cents: I would love to have macros which accept arguments, as in: map v(arg) Do-this-and-that-with-arg To use the macro, the user presses v, and vi prompts for the arg. Example: map #i(x) :'m,.s/^/x / Note that "x" takes on a special meaning in the substitute portion of this macro; it stands for a variable, not a literal "x". A literal "x" should be quoted, as in "\x", to override the macro substitution. This macro says that [from the point marked "m"] to [the current line] insert "x " in the beginning of each line, where x is to be specified. For instance, to comment-out a block of text in a fortran program, I can mark the beginning of the range with m, move to the end of the range, type #i, at which point vi will prompt me for the argument, I will type C, and then the macro will do the rest. The very same macro may be used to comment out a block of text in a TeX document; just respond with % to the prompt. In a sh or csh script respond with #. To insert "> " markers in replying to someone's mail, respond with >. To un-comment a block of text, I would use the companion macro: map #r(x) :'m,.s/^..// -- Rouben Rostamian Telephone: (301) 455-2458 Department of Mathematics and Statistics e-mail: University of Maryland Baltimore County bitnet: rostamian@umbc.bitnet Baltimore, MD 21228, U.S.A. internet: rouben@math9.math.umbc.edu
noraa@cbnewsk.att.com (aaron.l.hoffmeyer) (03/21/91)
In article <7220@ecs.soton.ac.uk> tjc@ecs.soton.ac.uk (Tim Chown) writes: >In <7214@ecs.soton.ac.uk> mrd@ecs.soton.ac.uk (Mark Dobie) writes: > >>In <1991Mar18.195343.665@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: > >>> I'm working on a "free" version of vi. It's to fully emulate the >>>current Berkeley-derived versions. After that, it's prettymuch a >>>free-for-all. >>> So .. what would you have added to vi, if you could? What would you >>>have made an option? What would you change? > >>Well, judging by what crops up in this group repeatedly you couldn't >>go far wrong in providing, > >>1) A built in way of justifying text. >>2) A more flexible way of editing several files and transferring >> between them. > >Yes please. And the ability to edit on columns rather than rows >would be useful in some circumstances. > >Tim I've heard several programmers wish for a more powerful rewind capability. For instance, when using tags to search through multiple files of source code, it would be great if the programmer could specify which file to rewind to, rather than always going back to the first edited file. You would probably have to increase the number of file buffers and make the rewind command more powerful, but I think the programmers would really get a kick out of it. Also, new user's of vi are completely lost for about the first two months and are really in trouble for the first few weeks. So, to help alleviate this common problem, maybe you could provide excellent documentation that would ensure that new users can effectively, efficiently and quickly learn how to use your editor. How about also including a great tutorial - one that can take a novice to advanced skills in multiple sessions. In other words, make it comprehensive, make it remember where the user has been, and make it fun to use - make them edit some really neat files. Refer to THE ULTIMATE GUIDE TO THE VI AND EX TEXT EDITORS by Hewlett Packard for the definitive vi documentation. Make your's this good and you'll win many friends. I've found people that have been using vi for literally six months that didn't even know how to make lines wrap. And few people, even excellent programmers, have a .exrc file that does much of anything. They start asking some really simple questions when thay have to use vi at say 2400 baud instead of the normal 9600. Make it as powerful as gnuemacs without the pinky cramps, but don't make it a memory hog. Provide a macro language that is more powerful and more intuitive than anything that exists in vi or gnuemacs (no LISP - we didn't all go to MIT - (rac (your brains))). Maybe something like the macro language in WordPerfect. How about making it recognize your key strokes while in macro programming mode, then let you edit it in macro editing mode? Oh, one more thing: include the BSD fmt command with your code. fmt is what I consider a required add-on for vi. Boy, if you could do all this, you could wind up on the cover of Newsweek. Aaron L. Hoffmeyer TR@CBNEA.ATT.COM In my journey to the end of the night, I must rely not only on dialectical paths of reason. I must have a good solid automobile, one that eschews the futile trappings of worldly ennui and asks only for basic maintenance. My Dodge Dartre offers me this elemental solace, and as interior parts fall off I am struck by the realization of their pointlessness. I may not know if the window is up or down. It is of no consequence. -- From an ad, JEAN-PAUL SARTRE FOR DODGE DARTRE, that once appeared in Reed College's student newspaper
cjc@ulysses.att.com (Chris Calabrese) (03/21/91)
In <1991Mar18.195343.665@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: > I'm working on a "free" version of vi. It's to fully emulate the >current Berkeley-derived versions. After that, it's prettymuch a >free-for-all. > So .. what would you have added to vi, if you could? What would you >have made an option? What would you change? Well, first off, I'm not quite sure that the world needs another vi clone. We already have stevie and elvis. Maybe the author should think about modifying one of these for their new features. That said, here's my wish list (some of these might already have been done in other implementations, but are not in standard vi from BSD or sV): 1) Unlimited line length 2) ksh like history editing - we've hacked up the vi we have around here to do this and it's really great. You can edit the : and / lines with all the regular vi editing commands, plus go forward and back through the : and / history file (j and k) and search the history (/ and ?). 3) better multi-file support - remember marks accross files, maybe even multi windows 4) X windows support - this has been done inside of Bell Labs, and had been done here for the Apollos a long time ago, but in both cases, it was done with an outboard program that sends the appropriate keystrokes to vi when you do things with the mouse Also, I think the idea of having simple formatting inside of vi is bogus. Vi is an editor, not a word processor. Besides, you can already get the desired effect using fmt. Let's not turn vi into emacs with moded editing. Name: Christopher J. Calabrese Brain loaned to: AT&T Bell Laboratories, Murray Hill, NJ att!ulysses!cjc cjc@ulysses.att.com Obligatory Quote: ``pher - gr. vb. to schlep. phospher - to schlep light.philosopher - to schlep thoughts.''
tif@doorstop.austin.ibm.com (Paul Chamberlain) (03/22/91)
bhoughto@pima.intel.com (Blair P. Houghton) writes: >tchrist@convex.COM (Tom Christiansen) writes: >> tilde as a range command "~E". >What's wrong with the current default action of ~ ? At the very least let me do "8~" and get the same thing as "~~~~~~~~". That should be easy. But, as has been stated, a little better programability would go a long, long way. It could be a design problem though. Paul Chamberlain | I do NOT speak for IBM. IBM VNET: PAULCC AT AUSTIN 512/838-9748 | ...!cs.utexas.edu!ibmchs!auschs!doorstop.austin.ibm.com!tif
rssutor@mace.princeton.edu (Robert S. Sutor) (03/22/91)
In article <1991Mar21.122928.939@cbnewsk.att.com> noraa@cbnewsk.att.com (aaron.l.hoffmeyer) writes: > ... > >Refer to THE ULTIMATE GUIDE TO THE VI AND EX TEXT EDITORS by Hewlett >Packard for the definitive vi documentation. Make your's this good and >you'll win many friends. > > ... What's the easiest way for someone to get a copy of this book? Is it available through bookstores or only HP? If the latter, who do you contact about ordering a copy? Thanks. Bob -- Robert S. Sutor Department of Mathematics Mathematical Sciences Department Princeton University IBM T.J. Watson Research Center rssutor@math.princeton.edu sutor@yktvmz, sutor@ibm.com
pfalstad@phoenix.Princeton.EDU (Paul Falstad) (03/22/91)
tchrist@convex.COM (Tom Christiansen) wrote:
>Here's my list. I already sent it in email:
Also, here's an idea: map the join-lines function to somewhere other
than J, and make H,J,K,L print some sort of error notice. I HATE being
in vi with the caps lock key on accidentally; by the time I notice, I've
joined a dozen lines of my file into one line, and there's no way to
undo it.
I'm sure there's a trivial mapping for this, but I'm too lazy...
--
Paul Falstad, pfalstad@phoenix.princeton.edu PLink:HYPNOS GEnie:P.FALSTAD
To boost the economy, I'd tax all foreigners living abroad.
Well, at least it's *FRESH* puke! -Basil Fawltypww@bnr.ca (Peter Whittaker) (03/22/91)
In article <3154@inews.intel.com> bhoughto@pima.intel.com (Blair P. Houghton) writes: >In article <1991Mar20.203643.26406@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >>Here's my list. I already sent it in email: >> visible marks. > >You can leave that out just fine. No blinky- >reversed box thingies for me, thanks. > How about making it customizable - I mean really customizable, i.e. you can toggle between options (blinky or noblinky) on a popup options menu (and the popup would be customizable - i.e. for some people it would be an edit session where they would edit .VIdefaults, while I would use a popup menu that would do the same thing - only using radio buttons, so I don;t have to go to man pages all the time). Then, make it so you could recompile it on the fly, absorbing the current options as program defaults. How about mouse-based block cut-and-paste? Perhaps using shift and ctrl to modify the pertinent mouse button actions? (I'm sorry - I'll submit this to the EDITORWISHLIST next time - I want EPM!) -- Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] Open Systems Integration pww@bnr.ca [ ] Bell Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7
elliott@quando.quantum.de (C. David Elliott) (03/22/91)
I'd like to be able to do column editing too sometimes. Also I'd like a much larger available set of buffers than just two, and better facilities for switching between them (yes I know its getting a bit like emacs but then I think this is a good feature of emacs). In the version of vi I use, macros made with map! (supposedly only evaluated in append mode) are evaluated in command mode too, and the same with abbreviations. This is a real pain sometimes and should be cleaned up. The ability to be able to do something like :.,.+50 <some substitution and editing commands, also with macros> What else then? Well some sort of control flow useable in macros (so they become more like proper functions) - 'if' would be a big bonus for a start. Argument passing to macros also would be nice (macros able to read arguments in from the user). Oh yes, how about changing the cursor appearance or a message in the info line or something to let you know when you are in append mode and when not (this might be there in some versions of vi - i don't know). oh yes, is there a way to yank a specified set of lines into a cut-buffer? Like: :120,145 "aY or :.,/}/ "aY ? If you can do this let me know please. If not then I'd like to see it in vi. Well that should be enough to keep you busy for the moment. Dave -- +---------------------+ | C. David Elliott | 'Eccles! What are you doing here?' | elliott@quantum.de | 'Everybody's got to be somewhere!' +---------------------+
wyle@inf.ethz.ch (Mitchell Wyle) (03/22/91)
In <1991Mar21.065353.1341@cs.ucla.edu> gast@maui.cs.ucla.edu (David Gast) fantasizes: >>>> So .. what would you have added to vi, if you could? What would you >>>>have made an option? What would you change? >I hope you mean a program like fmt, not one like nroff. what about something like curses-perl where you link (perhaps dynamically) pieces of your own (or Berkeley's or someone else's) code into the editor, making it object code extensible instead of lisp-interpreter extensible? ...not that I'd use it; it's just a thought. >Anyway, since fmt is freely available, I would just package it >with your program and leave it out of the editor. Nope; those of us who type over 100 wpm do not want to wait for {!}fmt^V^M to come back, even when it takes just a few hundred milliseconds. We want a wordstar-like ^B command built-in. This wish is #2 on my list. Sorry, fmt has to be a built-in. :-} >>>2) A more flexible way of editing several files and transferring >>> between them. > >More than one window on a file would be nice too. I've gotten used to vi the way it is; this one is not important to me. People coming from other editors want it; I guess it's important in general. >Here are some more ideas. In some cases, I recognize that they can be >done now, but in an inconvenient manner. > >1. All bugs fixed. I'm glad Dave has his priorities straight. I'll add: 0. Consistent or compatible with REAL UNIX vi. I complained three times to elvis author Steve Kirkendall (kirkenda@cs.pdx.edu) that elvis suffered from creeping featurism and was not consistent with Sun-OS vi, or any of the other Unix vi's I use. Elvis 1.4 does not interpret map macros correctly, dumps core on Sun-0S, and has enough inconsistencies for me not to use it on Unix (I use it on DOS). So: think big but start small. Make it stable, consistent and compatible with BSD vi, then add features. Don't let the neato features take all your time from fixing bugs or add some feature which makes your vi completely incompatible with the real vi. Steve's :cc command is good. The inability to let elvis wrap (forced sideways scrolling) is bad. I actually am getting to like the sideways scrolling, but I want a vi clone to be at least COMPATIBLE with the real vi. One should be able to turn features off when they conflict with BSD vi's methods, bugs, features, weirdisms. >5. Display lines of arbitrary length. emacs users can emacs executables and change hard-coded paths and other areas. I wish vi could do that... >David Gast Mitch Wyle
wyle@inf.ethz.ch (Mitchell Wyle) (03/22/91)
In article <1962@quando.quantum.de> elliott@quando.UUCP (C. David Elliott) asks: >To: elliott@quantum.de >oh yes, is there a way to yank a specified set of lines into a cut-buffer? Like: >:120,145 "aY >or >:.,/}/ "aY >? ja: 120Gma147G"ay`a Auf Zeil 120 gehen 120G Mit a markieren ma zu Zeil 147 gehen 147G Text yank'en "ay`a Das Makro ist nicht so schoen; meistens bin ich schon auf Zeil 120 und muss die oben erwaehnte erste Drei Buchstaben (120G) nicht eingeben.
edw@sequent.UUCP (Ed Wright) (03/23/91)
In article <7403@idunno.Princeton.EDU> rssutor@mace.princeton.edu (Robert S. Sutor) writes: %In article <1991Mar21.122928.939@cbnewsk.att.com> noraa@cbnewsk.att.com (aaron.l.hoffmeyer) writes: %> ... %> %>Refer to THE ULTIMATE GUIDE TO THE VI AND EX TEXT EDITORS by Hewlett %>Packard for the definitive vi documentation. Make your's this good and %>you'll win many friends. %> %> ... % %What's the easiest way for someone to get a copy of this book? Is it %available through bookstores or only HP? If the latter, who do you contact %about ordering a copy? Thanks. You local techie book store can get it ISBN 0-8053-4460-8 Benjamin/Cummings Publishing Co I paid $23.77 I'm still waiting for my copy of the Ex and Ed Editiors by Mohamaud AlLozzy which I am told the definitive book on the subject The local book store has slow on that one however. Ed -- I think I've got the hang of it now .... :w :q :wq :wq! ^d X exit X Q :quitbye CtrlAltDel ~~q :~q logout save/quit :!QUIT ^[zz ^[ZZ ZZZZ ^H ^@ ^L ^[c ^# ^E ^X ^I ^T ? help helpquit ^D ^d ^C ^c help exit ?Quit ?q anybackbone!sequent!edw edw@sequent.COM KA9AHQ 28.340
les@chinet.chi.il.us (Leslie Mikesell) (03/24/91)
In article <27674@neptune.inf.ethz.ch> wyle@inf.ethz.ch (Mitchell Wyle) writes: >>oh yes, is there a way to yank a specified set of lines into a cut-buffer? >>Like: >>:120,145 "aY >>or >>:.,/}/ "aY >ja: >120Gma147G"ay`a What's wrong with: :120,145 yank a or (my preference for most range-style commands) set a mark on the first line you want, move to the last line and reference the range as (assuming mark a is used) :'a,. y a Les Mikesell les@chinet.chi.il.us
pete@minster.york.ac.uk (03/24/91)
In article <7220@ecs.soton.ac.uk> tjc@ecs.soton.ac.uk (Tim Chown) writes: >In <7214@ecs.soton.ac.uk> mrd@ecs.soton.ac.uk (Mark Dobie) writes: > >>In <1991Mar18.195343.665@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: > >>> I'm working on a "free" version of vi. It's to fully emulate the >>>current Berkeley-derived versions. After that, it's prettymuch a >>>free-for-all. >>> So .. what would you have added to vi, if you could? What would you >>>have made an option? What would you change? > >>Well, judging by what crops up in this group repeatedly you couldn't >>go far wrong in providing, > >>1) A built in way of justifying text. >>2) A more flexible way of editing several files and transferring >> between them. > >Yes please. And the ability to edit on columns rather than rows >would be useful in some circumstances. > >Tim Welllll..... hmmm...... how can you improve on perfection :-) I'm in two minds about adding to vi -- although it's a great editor there's always the danger that adding too much to it will make it too big, slow and unwieldly (for example, I like MicroEmacs, but GNUemacs is ghastly). However, if I was in an ideal world where memory was free and processors infinitely fast, here are a few things I'd like (I'm assuming 100% vi compatibility is retained; these are all ``extras''.) The first is almost trivial: I'd like to be able to keep a history and edit my command lines properly! I know there are tricks involving yanking etc. but a proper history mechanism for ex commands and the ability to change previously entered commands would be really useful. Occasionally it would be nice to have proper ``2-D'' editing in vi -- i.e. ability to place the cursor *anywhere* on the screen and overtype -- several otherwise totally grotty editors like IBM's PE and PE2 have the ability to do this, along with the ability to play with arbitrary rectangular blocks of text. Also, how about emulating some of the nice features of Intel's AEDIT (a very nice, but terminally under-rated text editor)... for example, as well as the normal vi-type ``objects'' AEDIT allows the user to start a delete command with 'd', move the cursor arbitrarily around the file and then complete the command with another 'd'. AEDIT also has a sort of menu/help line at the bottom of the screen; since vi doesn't use the bottom line usually this could go in comparatively painlessly. Optional X11 or SunView support would be nice too -- click somewhere to move the cursor, some kind of cut/paste/delete mechanism... maybe hooks to allow menus as well? Naturally all new features should be completely invisible until explicitly invoked -- I want vi to look like ``classic'' vi unless I tell it otherwise... Pete Fenelon (pete@minster.york.ac.uk)
dylan@ibmpcug.co.uk (Matthew Farwell) (03/25/91)
In article <1991Mar20.203643.26406@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >Here's my list. I already sent it in email: > multiple windows. Yes. > no limits on line length, etc. > infinite undo buffer. > no more "can't yank/put in global/macro" errors. Of course. > editable commands lines with history and completion. I could live without this, but it'd be useful. > visible marks. Bleagh. <Blink blink blink>. > tilde as a range command "~E". Yes. yes yes. Please. ~~ for one character and ~w. How about ~G? > column mode Same as history completion. > 8 bit files. Get an international version of the software. The international versions of SCO Xenix + SCO Unix both include support for 8 bit stuff. Dylan. -- Matthew J Farwell: dylan@ibmpcug.co.uk || ...!uunet!ukc!ibmpcug!dylan If you've ever wondered how to get triangles from a cow, you need butter, milk and cheese and an equilateral chainsaw.
hansm@cs.kun.nl (Hans Mulder) (03/27/91)
In article <1991Mar23.204801.11908@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) asks: >What's wrong with: >:120,145 yank a Nothing wrong with that one. >or (my preference for most range-style commands) set a mark on the first >line you want, move to the last line and reference the range as (assuming >mark a is used) >:'a,. y a Too much typing. Why don't you simply say "ay'a ? I wholheartedly agree that one should use marks rather than line numbers whenever possible (i.e. always). >Les Mikesell > les@chinet.chi.il.us Have a nice day, Hans Mulder hansm@cs.kun.nl
toma@swsrv1.uucp (Tom Armistead) (03/28/91)
In article <1991Mar25.043842.20287@ibmpcug.co.uk> dylan@ibmpcug.CO.UK (Matthew Farwell) writes: >In article <1991Mar20.203643.26406@convex.com> tchrist@convex.COM (Tom Christiansen) writes: You need to get Emacs - and run the vi eumlation package (vip.el). I'm a vi fanatic from way-back - but now I've converted... It took a few hacks to the Lisp source (vip.el) to get exactly like I wanted, but I can make it do what ever I want too. Multiple windows, unlimited undo, compile from withing the editor, mail interface (sending and receiving), Usenet news reader, and on and on ... All in one package!!! (Oh yea - and Xwindow support). Tom -- Tom Armistead - Software Services - 2918 Dukeswood Dr. - Garland, Tx 75040 =========================================================================== {void,egsner}!swsrv1!toma mic!ozdaltx!swsrv1!toma {uunet,smu,ames}!sulaco!ozdaltx!swsrv1!toma
tchrist@convex.COM (Tom Christiansen) (04/05/91)
From the keyboard of toma@swsrv1.uucp (Tom Armistead): :You need to get Emacs - and run the vi eumlation package (vip.el). I'm a :vi fanatic from way-back - but now I've converted... It took a few hacks :to the Lisp source (vip.el) to get exactly like I wanted, but I can make it :do what ever I want too. Multiple windows, unlimited undo, compile from :withing the editor, mail interface (sending and receiving), Usenet news reader, :and on and on ... All in one package!!! (Oh yea - and Xwindow support). why the devil should an editor compile, read mail, or read news? emacs is just a visual shell. --tom
rwelch@isis.cs.du.edu (Randy S. Welch) (04/05/91)
In article <1991Apr04.193344.16407@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
why the devil should an editor compile, read mail, or read news?
I find being able to compile from the editor quite nice, if you have a
problem you can go right to it without having to remember what !@#!%!
line(s) you had a problem with. It's a good enough concept for MS-DOS
(:-O) compiler companies to use... ( editor wars are bad enough, OS ones..)
emacs is just a visual shell.
And I don't think you'll find too many arguments about that. I think that
Len Tower said once that you can think of emacs as a windowing system for
character based terminals.
I'll stick with my emacs :-)
-randy
--
Randy Welch Mail to : ...!ncar!scicom!bldr!randy or rwelch@du.edu
Boulder, CO rwelch@nyx.cs.du.edu or (303) 442-6717
"Unfortunately, life contains an unavoidable element of unpredictability"
-David Lynch "The Angriest Dog in the World"stevea@locus.com (Steve Anderson) (04/05/91)
In article <1991Apr04.193344.16407@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >why the devil should an editor compile, read mail, or read news? >emacs is just a visual shell. Regardless of what you call it %-), here's my HO of why emacs should read mail and news. (Compiling is not really done by emacs, think of it as :! cc filename.c &, or something like that.) If all you were going to do was _read_ mail and news, then no, you wouldn't need emacs. But, when you _write_ mail and post news, you might as well already be in the editor. Certainly both ways work...differing philosophies, as we all know. -- -Steve A. Anderson I do not speak officially for Locus or IBM, just me. stevea@locus.com ...{uunet|ucla-se|sequent}!lcc!stevea
martin@mwtech.UUCP (Martin Weitzel) (04/06/91)
In article <1991Mar20.203643.26406@convex.com> tchrist@convex.COM (Tom Christiansen) writes: > > editable commands lines with history and completion. You can have the first (more or less) if you fall into the habbit to 1) insert your command lines as normal lines of text 2) delete them into a named buffer 3) execute this buffer with the '@'-command 4) undo the changes, paste back and edit the line and go back to step 2 if the command did not what you wanted. Well, sounds a bit complicated but is much helpful if you know the command you type is going to get complex, e.g. some sort of substitute with marked portions of the matching pattern that must be reused in the replacement ... Of course, history and completion are not covered by this, but if you are going to "map" the key-strokes for the above steps 2+3 to an F-keys, you might also consider to append the command line to a history-file ... -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83