msb@cup.portal.com (Mark Steven Bilk) (04/03/91)
A new version of the CRISP editor is available from the author, Paul Fox, on a
shareware basis. It is some 20 revisions beyond the 1989 version (1.9).
Write to:
Paul Fox
8 Theobalds Way
Frimley
Surrey GU16 5RF
England
Home phone: +44 276 670 603
Paul has no Net access at the moment, but mail between the US and UK usually takes only
a week. UPS or FedEx can be used for greater reliability.
Probably the best time to reach him by phone is at 8 pm in England, which is 12
noon in California. Phone rates at this time are about $.90/minute ($54/hour,
not unlike consulting rates).
If you have a Sun SPARCstation you can send a 1.44MB (high-density) 3 1/2"
diskette; otherwise call or write for media arrangements.
You get the executable binary, the macros, and the macro compiler, so you can
modify most of CRISP's behavior (including all key bindings) and add your own
new routines. The documentation is present in a menu driven, on-line help
system.
The cost is $75 if you decide to use the software.
I have been using the old 1989 version for several weeks and it is excellent.
We recently received the new release, but I haven't had time to unpack it yet.
Paul tells me it has bug fixes, better documentation, and additional features,
including a mapping macro for Sun's current (Type 4) keyboard, used on
SPARCstations and Sun 4's.
* * * * *
Recently, Rasmus Lerdorf posted to this newsgroup:
>v1.9 under AT&T SVR3.2. Someone almost simultaneously posted a message
>about a Crisp mailing list to which I sent a message. I have yet to get
Would someone please re-post the info about the CRISP mailing list?
Or e-mail it to me at:
bilk@relgyro.stanford.edu
or msb@cup.portal.com
* * * * *
I have programmed under MSDOS for the last 8 years (editing with BRIEF), and on
mini-computers for most of the 20 years before that. So when I began working
with Unix (a much better operating system than MS-DOS) two months ago, I
expected it to have superior source code editing tools. I surveyed all the
editors the consultants could tell me about. What I found was rather
disappointing:
* vi can't provide more than one window onto a text file. Three or four
windows are commonly needed to simultaneously view global variables, a
subroutine and the code that calls it, source and destination of code to be
copied or moved, etc. Nor is it possible to open two or more copies of vi
in different SunView (or X) windows, each editing a different part of the
same file. They would corrupt the file when they wrote to it.
vi also has a difficult user interface and requires a change of mode even to
move the cursor off the current line.
* FrameMaker (a desk-top publisher) can open the same file multiple times, but
these windows don't know about one another. The result again is file
corruption.
* The Sabre-C programming environment provides very powerful debugging
facilities. Its mouse-based editor, however, allows only one window onto a
file.
* BRIEF can run inside a Sparc-emulated MS-DOS window. However, these windows
are limited to 25 lines of text, which is insufficient for real programming.
If several windows are opened, each displays about five lines, too little to
work with effectively.
I asked two Sun people, a consultant and a sales rep, if anything could be
done to increase the size of these windows or to get me the source code so I
could do it. Both were doubtful but said they would check and get back to
me; I'm still waiting. However, they did mention Sun's generous offer to
give us more lines of text by selling us a special VGA-type video card and
monitor for only $3000. I told them I'd let them know (and I will, too, as
soon as I can figure out why they are so darned reluctant to let us fix that
window software!)
* Textedit, the SunView mouse editor, can view a file through large multiple
windows. It has severe problems, however, in the area of text selection,
one of the most frequent editing operations. Text can only be selected by
means of the mouse, and the mouse arrow must be aligned very precisely to
get the selection right. Often, the selection will gain or lose a few
characters unless the mouse is held absolutely still while pressing the
buttons. This video game "point and shoot" activity makes editing take
about three times longer than with a purely keyboard oriented interface.
Textedit is also not programmable, which means its shortcomings cannot be
fixed.
* EMACS was the editor recommended by the Unix experts I asked. However, they
admitted that they tell people to use it so that they (the experts) will
have only one editor to support on all machines. I found EMACS to have
serious problems, some potentially correctable, some not...
A comparison of CRISP and EMACS:
* CRISP has a keyboard command interface that is rational, easy to learn and
requires a minimal number of keystrokes. Meta-W (a.k.a. Alt-W) writes the
current file to disk, Meta-S does a search, Meta-X exits, etc.
EMACS requires at least twice as many keystrokes for many commands, and the
letters chosen often have little relation to the function performed.
* CRISP allows very convenient cursor movement using the keypad arrow keys on
the Sun keyboard (also on the PC and others). You can move to:
Left and right one character
Up and down one line
Left and right one word (Ctrl-Left and -Right)
Beginning and end of the line (Home and End)
Page up and down (PgUp and PgDn)
Beginning and end of the file (Ctrl-PgUp and -PgDn)
Top and bottom of the window (Ctrl-Home and -End)
Left and right edges of the window (Shift-Home and -End)
EMACS only uses the cursor keys for left and right one character, up and
down one line. The other functions are performed with control-letter or
meta-letter keys (with hard-to-remember letters). This is supposed to allow
EMACS to run on the dumbest of terminals, such as a teletype, which lack a
cursor keypad.
My judgement is that if you have such a crippled keyboard, or a display that
shows only 25 lines, or some other impediment to good ergonomic
human-computer interface, you should GET RID OF IT! If you are a
professional programmer, your keyboard, screen, editor, and compiler are
your most essential tools; you need and deserve good ones. (By the way, I
don't mean to be a GNU-basher; I use gcc and love it.)
Another EMACS aggravation: when you cursor down to the bottom line of the
window, and then down one more line, does the window scroll up one line,
leaving the cursor at the bottom? No; it jerks up half the height of the
window, causing you to lose your place in the text!
* CRISP highlights the selected area of text (for copying, deletion,
searching, etc.) in reverse video, just like every other editor and word
processor I have ever seen, under both MS-DOS and the Unix clone QNX.
What finally convinced me not to use EMACS is that it does NOT distinguish
the selected region on the screen in any way. Yes, folks, incredible as it
seems, the selected region looks just the same as the rest of the text. It
isn't in reverse video, or underlined, or blinking, or a different color.
So how do you know where it is? The EMACS manual says you are supposed to
*remember*.
Well, if I am cutting and pasting 300 lines of my carefully written and
debugged code, I damn well want to SEE where it is!
It is only fair to mention that while the author(s) of EMACS omitted this
highlighting they did take the time to include something else--ELIZA the
electric psychiatrist. Maybe this is because, after using EMACS' bizarre
command interface and invisible selection region, you will NEED a
psychiatrist!
I spoke with EMACS consultants at Stanford and at Sun about this, and both
told me that it would require a major rewrite of EMACS to render the
selection in reverse video.
But that isn't all. Our Unix consultants told us that when you select an
area of text in EMACS you must use it in the very next command, since some
commands *change* the extent of the (invisibly) selected area, without
telling the user! (ELIZA, I'm ready for our session now!)
* CRISP has a relatively easy macro (internal programming) language. It was
originally a simplified form of LISP, but the compiler now also accepts a
simplified form of C.
The EMACS help system for its internal language (elisp) was not documented
and it took me a whole day just to learn how to access it. A cursory study
of its contents indicated that it might require a substantial knowledge of
LISP to be able to write macros for EMACS.
* A final piece of evidence: At one point I helped one of our staff members
by locating a bug in his C program, which he had been unable to find after
spending an entire day at it. It was a hard bug to pin down, since it
turned out to be in a header file that was #include'd in the file that was
failing. He said he had recently viewed the header file with EMACS but had
not altered it. I suspect he accidentally pressed some wrong key while in
EMACS that subtly mangled this file, but the point is that the user
interface of EMACS is so complex and confusing that it is easy to mess up
source code and thereby waste a great deal of time and energy.
You can probably fix some of EMACS' problems by mastering its programming
language and making extensive changes in its routines. You can probably also
get nibbled to death by a herd of mice.
Additional CRISP features (which aren't necessarily absent from EMACS):
* Easy selection of a region of text with only a couple of keystrokes. You
can select a span of complete lines, or a span of characters (which may
include multiple lines). The third choice is a rectangular area of text,
which is very handy for dealing with tabular data and diagrams.
* Any number of resizable, tiled windows, with multiple windows onto each file
and multiple files.
* Automatic usage of the full number of lines and columns of the terminal or
parent window (under X or Sunview).
If the parent window is resized, all of the internal tiled windows are
automatically resized proportionally (in the current version of CRISP).
* Unlimited and complete "undo" (back to the last writing of the file to disk),
including cursor movements and text selection.
* "Redo" to reverse the effects of "undo".
* Multitasking--operation of shells in one or more windows. You can compile
your source code in one window (to check syntax) while continuing to edit it
in another.
* After a compilation, CRISP moves the cursor to each error found by the
compiler in the source code you are editing, while displaying the error
message at the bottom of the screen.
MS-DOS is a terrible operating system (compared to Unix), mainly because it
places a size limit on the programs it will run. Yet many of its applications,
including programming tools, are better designed than their Unix counterparts.
I think this is because MS-DOS occupies a market share many times larger than
Unix, and the purchasing power of this customer base supports a great deal more
commercial software development than the Unix world enjoys.
For example, I would love to have a Unix equivalent of XTree Gold, the superb
MS-DOS file manager. (I tried the Unix "find" command, just to map the
directory tree, and it went out the NFS directory and never came back!)
There are probably half a dozen good programming editors running under MS-DOS,
with BRIEF the most widely used by far. For Unix, the only commonly available
editors are vi and EMACS. None of our consultants ever heard of CRISP.
Hopefully, that will change.
Mark S. Bilk
Stanford University Infinity MicroSystems
Hansen Labs, Gravity Probe B 2280 Latham St., Suite 12
Via Palou Mountain View, CA
Stanford, CA 94040
94305
415-725-4100 415-968-1065
bilk@relgyro.stanford.edu msb@cup.portal.com
---src@scuzzy.in-berlin.de (Heiko Blume) (04/05/91)
msb@cup.portal.com (Mark Steven Bilk) writes: >A comparison of CRISP and EMACS: which of the 1000 emacs variants are you talking about? > EMACS requires at least twice as many keystrokes for many commands, and the > letters chosen often have little relation to the function performed. see below. >* CRISP allows very convenient cursor movement using the keypad arrow keys on > the Sun keyboard (also on the PC and others). You can move to: > Left and right one character > Up and down one line > Left and right one word (Ctrl-Left and -Right) > Beginning and end of the line (Home and End) > Page up and down (PgUp and PgDn) > Beginning and end of the file (Ctrl-PgUp and -PgDn) > Top and bottom of the window (Ctrl-Home and -End) > Left and right edges of the window (Shift-Home and -End) if you try GNU emacs, you'll discover that it's configurable to do all that and much more versatile moving, especially context sensitive things 'End' goes to the end of line on the first press, to the end of paragraph on the second and to the end of buffer on the third press. if you don't like some key mapping, i.e. Cntrl-x-w for write-file, just go ahead and bind alt-w (or F1 or whatever) to that function, no problem! > EMACS only uses the cursor keys for left and right one character, up and > down one line. The other functions are performed with control-letter or > meta-letter keys (with hard-to-remember letters). This is supposed to allow > EMACS to run on the dumbest of terminals, such as a teletype, which lack a > cursor keypad. > that's true, you can run it on (nearly) any type of terminal. however, since it can not know beforehand what your personal terminal produces when you press ctrl-meta-shift-left-R9, you must tell it! fortunately that's quite easy... > My judgement is that if you have such a crippled keyboard, or a display that > shows only 25 lines, or some other impediment to good ergonomic > human-computer interface, you should GET RID OF IT! sounds more like 'crippled' administrators that don't provide a proper default configuration for their users. btw: GNU emacs can manage 300 by 300 character windows under X by default. you can compile it with higher values, if your screen is big enough for that. > If you are a > professional programmer, your keyboard, screen, editor, and compiler are > your most essential tools; you need and deserve good ones. (By the way, I > don't mean to be a GNU-basher; I use gcc and love it.) jesus! PLEASE try this in GNU emacs : [say, you have bla.c, blub.c and a Makefile that makes prgm out of both.] cntrl-x cntrl-f bla.c test() { int blub; printf("deliberate error!); } [change something in this buffer] Meta-x compile [emacs now asks 'save bla.c ?' - answer 'y'. you'll get a new window with gcc's output. it will complain of course. now type] cntrl-x ` [this will parse the gcc output and will take your cursor to the erroneous line in the bla.c buffer. emacs will also load the the file(s) that contain errors and move the cursor to the offending line when you enter cntrl-x ` ] you can also run gdb inside emacs etc... > Another EMACS aggravation: when you cursor down to the bottom line of the > window, and then down one more line, does the window scroll up one line, > leaving the cursor at the bottom? No; it jerks up half the height of the > window, causing you to lose your place in the text! again, that's configurable. EVERYTHING in emacs is configurable. > What finally convinced me not to use EMACS is that it does NOT distinguish > the selected region on the screen in any way. Yes, folks, incredible as it > seems, the selected region looks just the same as the rest of the text. It > isn't in reverse video, or underlined, or blinking, or a different color. > So how do you know where it is? The EMACS manual says you are supposed to > *remember*. > try epoch, the X Windowized emacs. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!] public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
cliff@demon.co.uk (Cliff Stanford) (04/07/91)
In article <40804@cup.portal.com> msb@cup.portal.com (Mark Steven Bilk) writes: > >Write to: > > Paul Fox > 8 Theobalds Way > Frimley > Surrey GU16 5RF > England > > Home phone: +44 276 670 603 > >Paul has no Net access at the moment Paul is now contactable as fox@demon.co.uk. Cliff. -- Cliff Stanford Email: cliff@demon.co.uk (Work) Demon Systems Limited cms@demon.co.uk (Home) 42 Hendon Lane Phone: 081-349 0063 (Office) London N3 1TT England 0860 375870 (Mobile)
colin@tcs.com (Colin Kendall) (04/20/91)
-- colin
colin@tcs.com (Colin Kendall) (04/20/91)
I thought I knew all there was to know about using vi until I started reading this group. From reading this group, I learned about the highly useful @ command. Which brings up some questions: 1. Is there any command which means "repeat the previous command-line"? 2. What do #, &, *, =, ;, :, ,, ., and ~ do when entered as commands? -- colin