richard@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
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.
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..."
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
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)
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
brunjes@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
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
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)
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
badri@valhalla.ee.rochester.edu (Badri Lokanathan) (03/18/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. In article <48@crdgw1.crd.ge.com>, barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: > >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. I heard about modeless editors like emacs and jove and thought to myself, man! don't those five vi/ex modes suck! I mean, like command mode and insert mode and append mode and change and visual mode. What blasphemy! I'd sell my soul for a modeless editor. Then I heard that salvation was near in the form of the new testament: Emacs, Jove, microemacs, GNUemacs. So I read the jove manual and came across the following: ----------- Cut and pasted from a teachjove session -------------------- The part of the mode line inside the parentheses is to tell you what modes you are in. The default mode is Text which is what you are in now. It is an example of a "major mode". There are several major modes in JOVE for editing different languages and text, such as C mode, Lisp mode, Text mode, etc. At any time one and only one major mode is active, and its two-letter code can always be found in the mode line just where "Text" is now. Each major mode makes a few commands behave differently. For example, what JOVE considers as part of a valid expression or an identifier differs from one major mode to another, since each programming language has a different idea of what is a legal identifier. Major modes are called major because there are also minor modes. They are called minor because they aren't alternatives to the major modes, just minor modifications of them. Each minor mode can be turned on or off by itself, regardless of what major mode you are in, and regardless of the other minor modes. So you can use no minor modes, or one minor mode, or any combination of several minor modes. ------------------------------------------------------------------------ Ah, no augmented and diminished modes: Lord have mercy. Then I tried the suspended 4th mode. IOT trap: core dumped. God. What a crock. Ah well, Bill Joy can drive his BMW or Acura (what does he drive, anyway?) I still love my rusty old Mazda. -- "I care about my fellow man {) badri@ee.rochester.edu Being taken for a ride, //\\ {ames,cmcl2,columbia,cornell, I care that things start changing ///\\\ garp,harvard,ll-xn,rutgers}! But there's no one on my side."-UB40 _||_ rochester!ur-valhalla!badri
templon@silver.bacs.indiana.edu (jeffrey templon) (03/19/89)
Well, now I think that is a little unfair. THere is a bit of difference between having an editor decide that tab means three spaces instead of two when you switch modes, and having "l" mean "move over one space" in one mode and "stick the letter l into the file" in another. jt
gast@oahu.cs.ucla.edu (David Gast) (03/20/89)
In article <3461@silver.bacs.indiana.edu> templon@silver.UUCP (jeffrey templon) writes: > >Well, now I think that is a little unfair. THere is a bit of difference >between having an editor decide that tab means three spaces instead of two >when you switch modes, and having "l" mean "move over one space" in one >mode and "stick the letter l into the file" in another. > > jt But even emacs has modes. Usually if you type Ascii printing characters they go into the file and if you type control characters or meta characters they are treated like commands, but ... 1) In emacs, there is mode which treats numbers as a count, not a character. So if you substitute "2" for "l" in your above argument, it still exists. 2) In Emacs, there is a mode for putting control characters in as text. 3) In Emacs, usually the Ascii printing chacter that is typed is inserted, I presume that there is a replace mode as well. (I never found it, but I presume it exists, it was always painful having to explicitly delete characters). 4) There is control-S for search strings (like / for search strings in vi). This is another mode. Presumably, there is another emacs mode to do regular expression searching. 5) There are modes to send something to the shell, for mail, etc. Show me an editor without modes and I'll show you a weak editor. David Gast gast@cs.ucla.edu {uunet,ucbvax,rutgers}!{ucla-cs,cs.ucla.edu}!gast
templon@silver.bacs.indiana.edu (jeffrey templon) (03/20/89)
I agree that an editor without modes is a weak editor. But I still insist that having cursor movement and text insertion be in completely separate, incompatible modes is a bit extreme. To me it is kind of like having a car in which you have to come to a complete stop before you can change directions. I should point out that I don't really know vi, just got acquainted with it long enough to hate it. It reminded me of SOS which I used on the VAX before we ever got VT100s. Lots of one-letter commands in one mode, and insertion in another, and never the two shall meet. jt
cosell@bbn.com (Bernie Cosell) (03/20/89)
In article <3469@silver.bacs.indiana.edu> templon@silver.UUCP (jeffrey templon) writes: } }But I still insist }that having cursor movement and text insertion be in completely separate, }incompatible modes is a bit extreme. I certainly agree with this.... but that statement is NOT true of vi. For some reason, folks either don't trip over in the docs, or else don't appreciate the use of, the "map!" command. Try this on your favorite vi (things in angle brackets are control chars): map! <esc>[D <esc>i then go into input mode and type "leftarrow". *surprise*! [.exrc available upon request...] __ / ) Bernie Cosell /--< _ __ __ o _ BBN Sys & Tech, Cambridge, MA 02238 /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com
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/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
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
liberte@m.cs.uiuc.edu (03/23/89)
> 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. Leif is that incremental parser. In GNU Emacs, with leif-mode, changes to your buffer are trapped and sent to the parser. Leif can load up a number of different language descriptions (bison and lex tables) to enable it to parse your text. When you ask for feedback, it can quickly tell you where your syntax errors are. Leif is free and available via anonymous ftp to a.cs.uiuc.edu. Mail to leif@cs.uiuc.edu for more info. Dan LaLiberte uiucdcs!liberte liberte@cs.uiuc.edu liberte%a.cs.uiuc.edu@uiucvmd.bitnet
woods@tmsoft.uucp (Greg Woods) (03/24/89)
In article <22009@shemp.CS.UCLA.EDU> gast@cs.ucla.edu (David Gast) writes: >But even emacs has modes. Usually if you type Ascii printing characters >they go into the file and if you type control characters or meta characters >they are treated like commands, but ... Yes, but this is always the case! It doesn't change and behave differently just because you move the cursor. Control characters are still ASCII. Just because some ASCII characters are inserted, and others cause something to happen, doesn't mean you have two different modes. I hope you meant this fececiously. > 1) In emacs, there is mode which treats numbers as a count, not > a character. So if you substitute "2" for "l" in your above > argument, it still exists. > 2) In Emacs, there is a mode for putting control characters in as text. I would consider these a case of entering a value when prompted, just like entering a filename for the save-file command. Nothing really modal about that, especially if your "mini-buffer" is a full fledged buffer supporting the complete set of commands. > 3) In Emacs, usually the Ascii printing chacter that is typed > is inserted, I presume that there is a replace mode as well. > (I never found it, but I presume it exists, it was always > painful having to explicitly delete characters). Any *real* Emacs user would NEVER use over-write-mode! :-) > 4) There is control-S for search strings (like / for search strings > in vi). This is another mode. Presumably, there is another > emacs mode to do regular expression searching. These are not different modes, but different commands which again require arguments and prompt for them in the mini-buffer. > 5) There are modes to send something to the shell, for mail, etc. Now we're talking modes. Some implemenations of emacs support such things as dired and bufed which are modes, and in fact they don't edit text on your screen at all, but "edit" directories or buffers. Same goes for the mail modes and news modes which manipulate messages. Shell mode is really just a window behaving like a pseudo-terminal. I've even seen 'vi' modes. Of course there are also the "language" specific modes which can do everything from assist pretty-printing to syntax checking. These are the real "modes" of emacs, and are actually applications implemented within (on, above, whatever) the basic editor. Again, most of these "modes" only re-map command keys and change the behavior of some commands. >Show me an editor without modes and I'll show you a weak editor. The key thing to remember about Emacs is that it "doesn't mode you in". You are never forced to do anything but what you want to do. If the command you execute promts for further input, such as a filename, you can always abort the command with a single keystroke. Most emacs', including GNU-Emacs, even let you undo what you have done. I don't want to bash vi either. I don't like vi for the simple fact that I learned to use a different full screen version of ed (fred), and then learne Gosling-Emacs and Multics-Emacs before I learned vi, and as such find vi difficult to do anything complex with because I can't remember that much about vi. Now, before I begin talking about WYSIWYG and expounding upon the virtues of post-edit document processors (such as troff or TEX), I'd better shut up! :-) -- Greg A. Woods. woods@{{tmsoft,utgpu,gate,ontmoh}.UUCP,utorgpu.BITNET,gpu.utcs.Toronto.EDU} 1-416-443-1734 [h] 1-416-595-5425 [w] Toronto, Ontario, Canada
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 <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>
eirik@elf.stanford.edu (Eirik Fuller) (03/27/89)
) >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. I've also found that dexterity with one mouse doesn't always result in immediate dexterity with another. I prefer the mouse in GNU emacs to most of the cursor positioning commands; I don't have to look at the mouse to use it. I'd have to reach for the meta key anyway, in a lot of cases, and with the mouse support I use (I rolled my own) I get more "bandwidth" than most motion commands; I can have three distinct locations in one maneuver: the cursor location at which text gets inserted, and the two ends of the region I'm grabbing (which might be in another "window"). That's all with a Logitech (mechanical) mouse on my Tek 4316; the Sun mice I've used (optical) make me understand why some Sun users I know sneer at emacs mouse support. The charitable way of saying this is that Sun's mouse is different and takes getting used to; someone who's suffered with one longer than I have can maybe offer an opinion on whether it does get better with practice; I am happy with my Logitech (though I'd consider scrapping it for a Sparc :-) I wonder, though, what the breakdown is on optical/mechanical vs mouse haters/mouse fans.
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...
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
amanda@iesd.dk (Per Abrahamsen) (04/03/89)
In article <10099@ihlpb.ATT.COM> gregg@ihlpb.ATT.COM (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. Just what the world needs: another programming language. Why invent a new language, when an existing (and widely used!) language like lisp fits perfecly. If you are a programmer, you will probably want to learn lisp anyway. > PROCEDURE split_window > > [ Long TPU procedure in a extended BASIC-style language deleted... -Pa ] Here is the same procedure in emacs lisp :-) ;; Define a new function "split_window" which takes no arguments "()". ;; (defun split_window () ;; ;; Online documentation of the function. ;; All functions in in emacs is documented this way. ;; "Split current window into two windows, one above the other. This window becomes the uppermost of the two." ;; ;; Allow user to call this function interactively. ;; (interactive) ;; ;; Call the primitive function "split-window" with the default ;; arguments "nil", which happens to do exactly what we want! ;; (split-window nil nil)) > 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. Try to say that on comp.lang.lisp... Anyway, GNU Emacs knows how to optimize (byte-compile) emacs lisp. > 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. Emacs is not optimized for VMS or VAX. Does DEC have a version of TPU for PMAX (MIPS + Ultrix)? > -- > Gregg Wonderly DOMAIN: gregg@ihlpb.att.com > AT&T Bell Laboratories UUCP: att!ihlpb!gregg -- Per Abrahamsen, amanda@iesd.dk, {...}!mcvax!diku!iesd!amanda
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
sommar@enea.se (Erland Sommarskog) (04/04/89)
Per Abrahamsen (amanda@iesd.dk) writes: >Why invent a new language, when an existing (and widely used!) >language like lisp fits perfecly. If you are a programmer, you will >probably want to learn lisp anyway. I must admit one thing: I have programmed for eight years and four years professionally, and I have never felt a longing to learn Lisp. Doesn't seem to be the langauges for the applications I'm usually involved with. The only reason to learn it would be to convert my Emacs profile to GNU. (And since I have played with Goslings MacLisp I have some notion on it.) Just face it, Lisp *is* a strange notation for many programmers. >> PROCEDURE split_window >> >> [ Long TPU procedure in a extended BASIC-style language deleted... -Pa ] > >Here is the same procedure in emacs lisp :-) >... > (split-window nil nil)) Another thing I don't like with Emacs. There are just too many things built into it. TPU offers you a much smaller set of built-ins, which allows you define your higher-level concepts as you want them. Emacs has a word concept, but of no use for me, since it's assuming thing I don't agree with. (Don't tell mw about syntax tables. Whether they are useful or not, it was easier write a move-by-word on character level instead.) So take all that extra stuff away, and get a smaller editor. It should be added that TPU also suffers from invalid assumption, particulary when it comes to case-insensitive searches. >Emacs is not optimized for VMS or VAX. So what is it optimzed for? Some weird Lisp machine far from common use? It was not a VAX running Unix anyway. -- 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...
mike@arizona.edu (Mike Coffin) (04/04/89)
From article <4407@enea.se>, by sommar@enea.se (Erland Sommarskog): > Emacs has a word concept, but of no use for me, since it's assuming > things I don't agree with. (Don't tell me about syntax tables. > Whether they are useful or not, it was easier write a move-by-word > on character level instead.) Move-by-word is not the only use for words; I count over a dozen commands that do various things to words. Not only that, but the natural meaning of "word" changes depending on what you're editing. (Is a dash part of a word? Not in C, maybe in English, certainly in Scheme.) By the time you abstract the concept of "word" away from its use --- so you don't have to duplicate the code in a dozen places --- and fix it so it's easily changed --- so you don't have to write a new word-recognizer for every language you edit --- you will have reinvented syntax-tables. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike Tucson, AZ 85721 (602)621-2858
neubauer@bsu-cs.UUCP (Paul Neubauer) (04/04/89)
In article <3861@mipos3.intel.com> woodstock@hobbes.intel.com (Nate Hess) writes: >[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? Actually, that is exactly how TPU does work. I even have a key bound to the equivalent of reevaluating a buffer for when I am editing .TPU source files, but even if I did not, it is not difficult to say 'execute(current_buffer)' from the command line (similar to M-x). >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. This is indeed the biggest problem with TPU. In fact, it is really worse than you have suggested because TPU does not even use DEC's method of making programs terminal-independent. VT dependence is hard-coded right into TPU. (Yes, I know that most terminals nowadays are ANSI, but there are still those of us who sometimes have to use other things as terminals and it is a real pain in the behind to have to keep a different, non-DEC, editor available just so that we can edit something on those occasions.) I like TPU, but it is certainly far from perfect, even if we are talking about the heavily customized versions of editors created with the TPU language and not DEC's stupidly crippled default TPU editing interfaces. -- Paul Neubauer neubauer@bsu-cs.bsu.edu neubauer@bsu-cs.UUCP <backbones>!{iuvax,pur-ee}!bsu-cs!neubauer
mart@euteal.UUCP (Mart van Stiphout) (04/05/89)
I dispute the necessity or desire to learn and use Lisp.
The language is a mess, numerous non orthogonal functions.
The program text is totally unreadable for anyone but
the Lisp adept.
As to emacs: I want an editor, not an environment. I have that
already. It is really unfair to compare vi and emacs.
Vi is excellent in what it is supposed to do, editing files,
not emulation the shell, rn, interpret C code, perform
window managing. We have all that.
= =
= =
= =
=================================================== Mart van Stiphout ======
= =
= =
= =
Mart van Stiphout
Eindhoven University of Technology
Design Automation Section
Dept. of Electrical Engineering
P.O.Box 513
5600 MB Eindhoven
The Netherlands
Email: mart@euteal.UUCP
(mcvax!hp4nl!eutrc3!euteal!mart)gregg@ihlpb.ATT.COM (Wonderly) (04/05/89)
From article <3861@mipos3.intel.com>, by nate@hobbes.intel.com (Nate Hess): > 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? TPU has two builtin procedures that make this easy. COMPILE takes a STRING or BUFFER or RANGE object and returns an object of type PROGRAM which can be passed to EXECUTE at any time. If the object compiled contains PROCEDURE definitions or other global assignments/definitions those take effect immediately. My VI emulator makes use of this to convert an RE to a TPU PATTERN (two entirely different things). If the pattern is in string format in the variable pat, e.g. (+ is string concat) pat := "LINE_BEGIN & SPAN(' ' + ASCII(9)) & 'switch'"; which represents the RE "^[ \t]*switch", I can say EXECUTE (COMPILE ("vi$global_var :=" + pat)); pos := SEARCH (vi$global_var, FORWARD, EXACT); to store the first location of text matching the pattern into the variable 'pos' (searching forward, matching case exactly). It really is superior to lisp and a lot more readable! -- Gregg Wonderly DOMAIN: gregg@ihlpb.att.com AT&T Bell Laboratories UUCP: att!ihlpb!gregg
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
jpdres10@usl-pc.usl.edu (Green Eric Lee) (04/14/89)
In article <10141@ihlpb.ATT.COM> gregg@ihlpb.ATT.COM (Wonderly) writes: >From article <3861@mipos3.intel.com>, by nate@hobbes.intel.com (Nate Hess): [Re: TPU superior to LISP?] >It really is superior to lisp and a lot more readable! Don't you mean that "TPU is more similar to Pascal than Lisp is", rather than, "TPU is superior to Lisp"? This tends to imply that being Pascalish is better than being Lispish. As a sideline Lisp fan (esp. the Scheme dialect), I find that to be a bit, err, reversed. Certainly most people here will know Pascal. After all, it IS the standard introductory level language for most CS departments. However, I shudder to think that there are professional computer programmers out there who have never written programs in Lisp, who, for that matter, have never even encountered Lisp. What college did these so-called "computer scientists" graduate from? Northwest Mississippi Community College and Day Care Center? (Yes, it's unsuited for novice users -- so what?) >Gregg Wonderly DOMAIN: gregg@ihlpb.att.com -- | // 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 << |