lewis@bnrmtl.bnr.ca (Pierre Lewis) (02/22/91)
I've come across and used quite a few different editors in my 15+ years in
the business: starting with keypunches, edlin style editor on real TTYs
(PDP-8), many full-screen editors (vi, SPF, XEDIT, PE2, Brief, Turbo C's,
EVE, and other proprietary editors), and a few word-processor (WP5.0,
Publisher).
I find discussions on editors in general very interesting (comp.editors is one
of the few newsgroups I regularly read). I've been wanting to organize my
thoughts on the topic for a while and finally did it. Here's what came out --
hopefully will be of some interest, esp. to those who are developing editors.
Of course it's one person's opinion, and it seems to be a minority opinion.
ON VI
But first a word on vi.
Vi is not my favorite editor (-: stands for VeryIrritating, doesn't it? :-).
But there is one VERY GOOD THING about it: it's universally available on all
Unix systems (and then some) and works on practically any terminal. Because
of this, anyone using Unix professionally should certainly be sufficiently
familiar with this editor to do useful work. But for most of my work, I
prefer something else!
And I agree it's a powerful editor that anyone can get used to without too
much work (at least for a minimum subset). But I think it is also lacking in
some important features such as the ability to edit multiple files at the
same time (and copy stuff between them). And personally, I don't like its
user interface, esp. the modal functioning.
The first time I came in contact with Unix and C was at an introductory
course on above topics. We had the choice between vi and emacs and frankly I
don't think either editor is very intuitive and will let one be comfortable
in two or three days. For such a course, something simpler would be needed.
Vi may well be the preferred editor of some people (and that's fine), but the
number of requests in comp.editors for a simple editor on Unix indicates (I
think) that vi is not the ideal solution. I haven't seen such a request for
DOS yet, surely because there is no lack of good editors here including
simple ones in this environment (e.g. even IE that came with my PS/2 is very
simple and yet quite sufficient to edit CONFIG.SYS, etc).
Maybe that some of my criticism about vi is unjustified and is due to my lack
of knowing how to use it properly.
THOUGHTS ON WHAT A USER INTERFACE SHOULD BE LIKE (AND HENCE EDITOR FUNCTIONS)
The following summarizes what I think the interface and functions of a text
editor should be like. A text editor is the tool a software developer spends
a good portion of his/her time working with (for program development of
course, but also for e-mail and simple documentation). Does not apply to a
word processor. Of course it's my preference and there will never be one
single editor for everybody.
1) Display should be WYSIWYG. This means (to me!):
a) Strict window on file: just as it is in general not possible to see all
lines of a file, I also don't need to see all columns. I don't like
editors that wrap lines. For two reasons:
- 1st, it can hide the indententation of a fragment of program. For
example, the following bit of C code
| if (gPcvcb->vcol + gPcvcb->rccol > gCurlgt - tlgt)
| {
| gCurlgt = gPcvcb->vcol + gPcvcb->rccol + tlgt;
| if (gCurlgt > LSZ)
| {
| gCurlgt = -1;
| return FALSE;
| }
| }
becomes in a small window
| if (gPcvcb->vcol + gPcvcb->rcc|
|ol > gCurlgt - tlgt) |
| { |
| gCurlgt = gPcvcb->vcol + gPc|
|vcb->rccol + tlgt; |
| if (gCurlgt > LSZ) |
| { |
| gCurlgt = -1; |
| return FALSE; |
Structure is now harder to read, and (and two extra horizontal lines
are needed so we see less of the structure).
- 2nd, it often misleads writers into thinking their text is OK when
in fact it isn't (I've seen that often in e-mail). For example, they
see:
Strict window on file: just as it
is in general not possible to see
all lines of a file, I also don't
need to see all columns. I don't
like editors that wrap lines. For
two reasons:
But their file is in fact...
Strict window on file: just as it (unintentional long line
is in general not possible to see
all lines of a file, I also don't need to see all columns. I don't
like editors that wrap lines. For
two reasons:
I just saw exactly such an example in a comp.editors article! One
could detect this with careful observation of cursor behaviour, or by
resizing the window. But otherwise it's not obvious. What the
writer is going to get when he/she saves his/her work isn't what
he/she sees.
What I prefer is an editor that shows what it can of a given line and
of course allows one to scroll right (and left) just as one can scroll
down (and up). Optionally, it can signal long lines thru a special
char (e.g. "!") at the end of the displayed portion of the line. With
such an editor, if one unintentionally writes a long line, the editor
will somehow (e.g. by scrolling horizontally) tell him.
b) Editor automatically strips trailing blanks (they can't be seen so they
should not exist). I remember one colleague wasting hours trying to
understand why his few-line macro wouldn't work.
#define etrace(msg) \
if(stdtrace) fprintf(stdtrace, "%s %d (%d): %s\n", \
__FILE__, __LINE__, (int)(time(0)%300L), msg)
The reason, it turned out, was that his favorite editor left a trailing
blank (which he, of course, had accidently typed) following one of the
"\" with the result that it no longer meant continuation. I don't know
of any application where trailing blanks are useful (and then there's
always vi). Granted, an editor that strips trailing blanks can't edit
some uuencoded files. But I've done that once in 3 years (with vi).
c) Tabs are expanded, again because they're invisible. In addition tabs
tend to be a nuisance since people attach different values to them and
because they are sometimes used to compress file transmission (e.g.
PROCOMM I think). But tabs are a necessity at least in makefiles and
some way of keeping them is of course needed. When I look at tabs in
source code (my editor shows them if I want to keep them), I invariably
see inconsistant usage (some lines with, some without); what's the use?
I prefer to use tabs for positioning (as in PE2 and XEDIT), not to
insert data.
d) Non-modal. The main reason is I can't tell from looking at the display
what mode I'm in and I guess I have a poor memory (and, in vi, keep
forgetting to hit ESC). WYS does not tell you what mode you're in.
In addition, another thing I want (and which frustrates me no end on vi)
is total freedom of movement in the window and automatic scrolling when
cursor hits a border. If the cursor is in some position in my window on
the file (say at the end of a long line) and I hit cursor down, I want the
cursor to move DOWN, not SIDEWAYS! The fact that the next line is shorter
shouldn't be an excuse. If I now enter a character at that position, it's
up to the editor to extend the line (with blanks I guess). Note that this
implies that trailing blanks are removed and that tabs are expanded. This
way I can add asterisks on the right of a comment block simply by typing
"* Down Left * Down Left * ..." instead of having to tab to it from the
ragged ends of my text for each line. Another advantage of not moving
sideways is that you can use the cursor to "remember" a column position as
you scroll down or up.
On the display, I like a status line and expect a command line.
2) Editing keys
This is a controversial topic. Clearly WP5.0 style is far from ideal (too
many combinations, impossible to remember).
What I prefer (although I recognize it limits range of terminals) is
keypad for general positioning (page down/up, next file, insert/replace
mode) and c-keys (or alt keys on a PC) for editing (c-y for yank, c-r for
repeat line, c-x for delete &c). Use of a keypad is typical of VAX/VMS
editors (EDT, EVE) for example. I see two user modes when using an editor,
browse mode (looking for stuff) and edit mode. I like to associate browse
functions to keypad, editing ones to keyboard. And I don't mind moving my
hand a few centimeters when switching modes. A definite plus however is
for the editor to be able to function without a keypad (even if it's less
convenient).
3) Essential features:
- EASY TO LEARN and as INTUITIVE as possible. An editor that comes with
300 pages of documentation is NOT easy to learn. SMALL is beautiful
also applies (i.e. you shouldn't need one meg to edit an hello-world
program).
- Basic features: insert/edit, intelligent split/join, search/replace,
delete lines, yank lines and the like. Autoindenting of new lines.
Support for non-printing characters (such as FFs, ESCs, TABs if kept)
that may be in file.
- Multiple (at least 2!) files simultaneously with of course possibility
to move stuff from one to another. Typically organized in a ring.
Should be able to name multiple files on command line, e.g. ed *.c.
- Block operations (moving groups of lines for example). PE2's block
operations are really good (blocks can be lines, streams, rectangles).
- Undo or (at a minimum) recover facility.
- Protection against destructive writes. For example, vi allows the
following: user1 and user2 are both editing the same file. User1
saves his work and then user2 saves his work thereby destroying
user1's work (this latter save should be refused because the file is
no longer the same as when it was read in).
4) Very useful features:
- Multiple (at least 2) views simultaneously of same/different files.
- Access to system (shell) without quitting editor. In particular,
possibility to pipe the output of a command into the editor (in a new
"file", e.g. <ls -l), or to pipe the current file into a command (e.g.
>diff - orig.file). Or even both together, to filter a file. Maybe
this belongs in the previous section (at least in part).
- Autosave or some other mechanism to prevent complete loss of a session
on power failure.
- RE searching: at the risk of shocking a lot of readers, I'll say that I
don't find this very useful (except in ed scripts and the like). The
reasons are
- the meta-characters are not intuitive,
- I usually know what I'm looking for (typically names),
- the characters used in REs are also used in C programs with the result
that the search is often not what I expected.
Why not "s/string/" for simple search, "rs/string" for RE-search or
something like that?
- Right/left shift of groups of lines as when adding an if statement around
a bit of code.
- Marks (e.g. to quickly return to a given spot), direct line addressing.
- Macros. Or learn mode.
- A minimum of WP features: word wrap and paragraph reflow are very
useful (as in PE2), particularly for e-mail. I'd even add spell
checking to the nice-to-have features.
- Adjustable window size (for xterms).
5) Nice-to-have features:
- Hex editing/viewing. The viewing is the more useful of the two.
- Line exclusion (possibility to exclude a group of lines from being
displayed - useful to better see a complex structure, e.g. by hiding
uninteresting code that clutters a switch statement).
- Sort feature. First met this on CMS's XEDIT and find it very useful
in all sorts of situations (not only for acronym lists).
- Many people would name redefinable keys as a worthwhile feature. I
find it's more of a nuisance than fixed definitions. It means that
when you go help a colleague you're not going to be comfortable editing
under his/her account because the keys now mean different things.
You might even do damage under some conditions e.g. if one key that you
use for something trivial causes the whole file to be reflowed.
6) Other observations
- In general (but not for word processors), I prefer an editor that is
line-oriented as opposed to character-oriented. E.g. in such an editor
you can't join two lines by deleting the CR between them but you do it
thru a special function key. Or you can yank a group of lines without
having to be in the first column of the lines. The reason is that most
programming I've done/seen is basically line-oriented. You move groups
of lines around, not groups of characters. One counterexample: block
operations in Turbo C are only character-oriented (stream).
- I don't personally like an editor that jumps around to show me ()
matching and the like. If it's available, I want to be able to turn it
off. I tend to write the two together and then insert within.
- Guess-typing by the editor (I seem to have heard of that at one point)
would drive me insane because it would force me to continuously control
what's going on.
- Integrated environments (e.g. Turbo C, Saber-C). In all cases, I would
like to have the choice of installing my own editor. Otherwise I am
forced to learn yet another editor (and not typically one I'm comfortable
with).
On PCs, one editor stands out that is very close to above requirements. It's
PE2 (discussed recently in this news group). And on CMS there is XEDIT
which, given the unusual environment under which it works, is also very good.
But on Unix (my usual environment), I didn't find anything that came close.
So, rather than complain, I thought it would be fun to write my own, and this
turned out to be a fascinating exercise. And the gain in productivity was
well worth the effort (a few hundred hours for about 6 klocs). Of all the
features I put in it that I don't find in vi, the most time-saving are
paragraph reflow (for e-mail and doc) and multiple files. And the big
advantage is that you can port your editor to whatever environment you work
on (e.g. in my case a few Unixes and VAX/VMS). But I don't pretend or even
think it could ever replace vi. For one thing, it's limited to vt100s (and
emulations thereof such as xterm), and it's probably a bit too customized to
to one specific user (although a few others actually use it). It's called
"led" (as in Let's Edit Differently).
--
Pierre LEWIS
Internet: bnrmtl!lewis@Larry.McRCIM.McGill.EDU
Alternate Internet: piotr@pmc.umontreal.ca (in case all else fails)
P.S. - The ideas above are mine. My work does not involve writing editors
(although that would surely be fascinating), but OSI.peter@ficc.ferranti.com (Peter da Silva) (02/23/91)
Whether an editor should wrap lines is a matter of taste, and de gustibus non est disputandum (the windy bus is not arguing). I like wrapped lines because I don't like the editor hiding things from me. Other people don't. An ideal editor allows this to be an option changeable at a moment's notice. Stripping trailing blanks, turning tabs into spaces, and so on... that should again be an option. I don't like an editor making changes to the body of my file without my consent. Other people could care less about the purity of the bits. One useful feature of the old Wang WP systems was that all spaces, tabs, and so on were visible. Perhaps this should be part of the word processing mode (yes, mode). I like modal editors, because I like to keep my fingers on the keyboard, so function keys are useless to me. (aside, one reason I like Microsoft Windows user interface, for all its obscene cruft, is that it doesn't force me to use a mouse). If some sort of alt key were standardised this would be less of a problem, though this leads to I18N confusion when ALT becomes overloaded with diacriticals and the like. This gets into editing keys. I don't use them. When using an editor that requires them I find they break my concentration. They should be optional. Ideally the whole keyboard should be bindable, but one of the default bindings should put all the commands under my fingers. This would avoid the "other guy's macros" problem. When browsing, I prefer to use a mouse. When editing, the keyboard. Function keys and keypads are at best a poor compromise. But don't keep people from using them! Speaking of which, key bindings, macros, and the like MUST MUST MUST be in plain text files I can edit. This goes for all other setup files for other programs as well. Moving beyond the end of a line... again, a matter of taste. Some people think of a file as a plane, others as a stream. If you're a stream person putting characters where there is no line causes instant cognitive dissonance. Some people think boxes of stars for comments are the greatest thing since sliced bread. I just think of what a pain they cause for programs that want to extract information from comments, and reformatters. If you really want to do this, I'd say implement column editing as well so you can insert your pretty text box with "* return * return * return ..." Block operations are a subset of column operations. You should also be able to have sticky columns, where inserting a line inserts it outside the currently active editing region. Note that VI does remember the column position, and puts you back in the right place when you get to a longer line again. On the display, I expect as much text as will fit... at least on a terminal. If I can't get close to 24 by 80 I get cranky. Things like showmatch are nice, but an implementation where it highlighted the matching character would tend to be more useful. Perhaps make this one of the "select" modes. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
jch@dyfed.rdg.dec.com (John Haxby) (03/04/91)
In article <13O9MVA@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: |> I like modal editors, because I like to keep my fingers on the keyboard, so |> function keys are useless to me. This doesn't follow. Non-modal editors can behave quite well without using function keys. Unless, of course, you regard the CTRL or ALT or META keys as being off the main keyboard--or you just don't like holding down a key while you type something else (in which case, one could assume, use use CAPS or SHIFT lock a lot :-) -- John Haxby, Definitively Wrong. Digital <jch@wessex.rdg.dec.com> Reading, England <...!ukc!wessex!jch>
einari@rhi.hi.is (Einar Indridason) (03/04/91)
In article <13O9MVA@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: ... > >Speaking of which, key bindings, macros, and the like MUST MUST MUST be in >plain text files I can edit. This goes for all other setup files for other >programs as well. > AND the editor is NOT to MASK the 8th bit. The editor **SHOULD** leave the 8th bit **ALONE**. (otherwise, the programmer might be wanted dead or alive here in Iceland, preferably dead.) -- Internet: einari@rhi.hi.is | "Just give me my command line and drag UUCP: ..!mcsun!isgate!rhi!einari | the GUIs to the waste basket!!!!" Surgeon Generals warning: Masking the 8th bit can seriously damage your brain!!
mayoff@cs.utexas.edu (Robert Mayoff) (03/05/91)
In article <1991Mar4.085038.4092@hollie.rdg.dec.com> jch@dyfed.rdg.dec.com (John Haxby) writes: >In article <13O9MVA@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: >|> I like modal editors, because I like to keep my fingers on the keyboard, so >|> function keys are useless to me. >This doesn't follow. Non-modal editors can behave quite well without using >function keys. Unless, of course, you regard the CTRL or ALT or META keys >as being off the main keyboard--or you just don't like holding down a key >while you type something else While I regard CTRL, ALT, and META as being part of the keyboard, I have two problems with using them for command sequences. One is that ALT and META are non-standard - not all terminals have them, and those that do handle them in different ways. ESC can be used instead; however, you can't use ESC like a normal shift/control key, because it sends its ASCII sequence once - i.e., you can't send ESCxESCc by holding down ESC and pressing xc. You must press the ESC key twice. My main problem, though, with non-modal editors (emacs in specific) is that, as oyu said, I just don't like holding down a key while I type something else. If I need to perform several editing commands without any interspersed text entry, I don't want to have to press ESC, META, ALT, or CONTROL for every command (or several times per command, as is oft the case with emacs). That's why I like vi - the most useful editing commands are a single keystroke, with no extra modifier keys. Hitting ESC to get into command mode and pressing one of "acios" to get back into insert mode, is, in my estimation, more keystroke-efficient than pressing ctrl or meta (or both) for every editing command. -- /_ rob <mayoff@cs.utexas.edu> /_ Fun things to do with UNIX (#2 in a series): / echo "rsh `hostname` -n source eat.cpu &" > eat.cpu; source eat.cpu
peter@ficc.ferranti.com (Peter da Silva) (03/06/91)
In article <1991Mar4.085038.4092@hollie.rdg.dec.com> jch@dyfed.rdg.dec.com (John Haxby) writes: > In article <13O9MVA@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > |> I like modal editors, because I like to keep my fingers on the keyboard, so > |> function keys are useless to me. > This doesn't follow. Non-modal editors can behave quite well without using > function keys. Not on normal terminals. At least, I haven't found one that satisfied me. > Unless, of course, you regard the CTRL or ALT or META keys > as being off the main keyboard Well, control keys are a pretty limited selection unless supplemented by function keys, or unless you get into lots of multi-character sequences. DEC's EDT is an example of the first solution, and Emacs on standard terminals an example of the second. And most keyboards don't support ALT or META keys. > --or you just don't like holding down a key > while you type something else (in which case, one could assume, use use > CAPS or SHIFT lock a lot :-) You could always think of "ESC" as being "meta-lock" in vi. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
xiaoy@ecf.toronto.edu (XIAO Yan) (03/06/91)
> >While I regard CTRL, ALT, and META as being part of the keyboard, I have two >problems with using them for command sequences. One is that ALT and META are >non-standard - not all terminals have them, and those that do handle them in >different ways. ESC can be used instead; however, you can't use ESC like a >normal shift/control key, because it sends its ASCII sequence once - i.e., you >can't send ESCxESCc by holding down ESC and pressing xc. You must press the >ESC key twice. > >My main problem, though, with non-modal editors (emacs in specific) is that, as >oyu said, I just don't like holding down a key while I type something else. If >I need to perform several editing commands without any interspersed text entry, >I don't want to have to press ESC, META, ALT, or CONTROL for every command (or >several times per command, as is oft the case with emacs). That's why I like >vi - the most useful editing commands are a single keystroke, with no extra >modifier keys. Hitting ESC to get into command mode and pressing one of >"acios" to get back into insert mode, is, in my estimation, more >keystroke-efficient than pressing ctrl or meta (or both) for every editing >command. As one of vi-lover, I would see someday that mouse can be added in to perform some task, like cut/paste. Maybe this is too hardware-specific. Of course I am not working with console all the time, but sometimes when you are with console.... Xiao
lewis@bnrmtl.bnr.ca (Pierre Lewis) (03/12/91)
I got quite a few replies to my original post. Here are a few followup points.
a) vi supports multiple files
A few wrote saying that vi does support multiple files. Well, in a way,
it's true, but it's not quite what I mean. I think I would say that vi
supports sequential editing of files (with a rewind possibility (:rew)).
At any one point, only one file is in memory. Except for the possibility
of copying stuff from one file to the next, I see little difference
between
vi eins zwei drei
and
vi eins ; vi zwei ; vi drei
What I mean for example is, as I edit say some.c, I go for a minute to
project.h to add some #define and then come back to some.c in the same
spot (the editor of course remembers where one was).
b) other editors
Many people wrote about other editors, especially emacs which in fact can
be made to behave much like I want. But this takes quite a bit of initial
work to learn to set it up properly. We have it here, many people use it,
I've tried it, but I find it's too heavy. Other editors were mentioned
(JOVE, mined, ...) that I don't know about, in addition to KEDIT (which I
do know about and forgot to mention - it combines the best of PE2 and
IBM's XEDIT in one editor).
c) writing your own editor
What prompted me to write my own editor was an interesting article by
Dorian P. Yeager, "Customize Your Text Editor" in Computer Language,
March 1987. Some points he makes is that you can then have basically the
same editor in all your environments and port your editor as a way to
learn a new system (that's exactly what I did when I had to work on
VAX/VMS recently: I first ported my editor; the painful part was learning
EVE for the bootstrap).
Otherwise, some people agreed with my preferences, others didn't, which goes
to show that no single editor will ever fill the bill for everyone! And that's
fine so!
--
Pierre LEWIS
Internet: bnrmtl!lewis@Larry.McRCIM.McGill.EDU
Alternate Internet: piotr@pmc.umontreal.ca (in case all else fails)
P.S. I'll try (in the next few days - I was away from the office) to reply
to everyone who sent me e-mail directly, otherwise e-mail problems (in or
out) will be the probable cause.tchrist@convex.COM (Tom Christiansen) (03/12/91)
From the keyboard of bnrmtl!lewis@larry.mcrcim.mcgill.edu: :I got quite a few replies to my original post. Here are a few followup points. : :a) vi supports multiple files : : A few wrote saying that vi does support multiple files. Well, in a way, : it's true, but it's not quite what I mean. I think I would say that vi : supports sequential editing of files (with a rewind possibility (:rew)). : At any one point, only one file is in memory. Except for the possibility : of copying stuff from one file to the next, I see little difference : between : vi eins zwei drei : and : vi eins ; vi zwei ; vi drei No, you lose buffer information in the 2nd method, so it's not the same. : What I mean for example is, as I edit say some.c, I go for a minute to : project.h to add some #define and then come back to some.c in the same : spot (the editor of course remembers where one was). If you use switch between % and # with control-^, vi of course remembers where you were. --tom
peter@ficc.ferranti.com (Peter da Silva) (03/12/91)
In article <1991Mar11.163554.21156@scrumpy@.bnr.ca> bnrmtl!lewis@larry.mcrcim.mcgill.edu writes: > A few wrote saying that vi does support multiple files. Well, in a way, > it's true, but it's not quite what I mean. ... It's not as nice as emacs, but it's really a useful ability. Of course, until you've used an editor that doesn't let you easily switch between files (say, for example, EDT on VMS) you really can't appreciate it. (I once freaked out a DEC user simply by doing a shell-escape in an "ed" clone I was writing on RSX-11. It's amazing the things you get used to in UNIX that just don't work elsewhere.) > What I mean for example is, as I edit say some.c, I go for a minute to > project.h to add some #define and then come back to some.c in the same > spot (the editor of course remembers where one was). VI does this. I do this all the time. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
meissner@osf.org (Michael Meissner) (03/13/91)
In article <1991Mar11.192122.18883@convex.com> tchrist@convex.COM (Tom Christiansen) writes: | From the keyboard of bnrmtl!lewis@larry.mcrcim.mcgill.edu: | :I got quite a few replies to my original post. Here are a few followup points. | : | :a) vi supports multiple files | : | : A few wrote saying that vi does support multiple files. Well, in a way, | : it's true, but it's not quite what I mean. I think I would say that vi | : supports sequential editing of files (with a rewind possibility (:rew)). | : At any one point, only one file is in memory. Except for the possibility | : of copying stuff from one file to the next, I see little difference | : between | : vi eins zwei drei | : and | : vi eins ; vi zwei ; vi drei | | No, you lose buffer information in the 2nd method, so it's not the same. However, vi only gives you one alternate file, so if you have more than 2 files, you lose. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
xiaoy@ecf.toronto.edu (XIAO Yan) (03/13/91)
In article <MEISSNER.91Mar12115840@curley.osf.org> meissner@osf.org (Michael Meissner) writes: (lines deleted...) >However, vi only gives you one alternate file, so if you have more >than 2 files, you lose. (lines deleted...) Are you serious? Or are you using some pecular programme calling itself vi? Or you are insulting our intelligence!! Xiao
tchrist@convex.COM (Tom Christiansen) (03/13/91)
From the keyboard of meissner@osf.org (Michael Meissner): :However, vi only gives you one alternate file, so if you have more :than 2 files, you lose. Well, all your buffers stick around. It's only the line/char position information on the alternate file that is lost. You also keep around things like last search pattern, last substitution, last text inserted, etc, all of which can be quite handy. --tom
Dan_Jacobson@ATT.COM (03/13/91)
>>>>> On 12 Mar 91 23:09:24 GMT, leech@vangogh.cs.unc.edu (Jonathan >>>>> Leech) said: J> Probably the nicest thing about VMS I encountered was that it J> detached and preserved jobs - including editor sessions - when the J> network connection dropped. With Oliver Laumann's "screen" program [from comp.sources.unix archives, FTPable from e.g., uunet.uu.net] with my up to 10 windows I can reconnect after a hang up, or disconnect, walk to a groovier office, then reconnect. Cursor stays just where it was, etc. [Compiles on Sun/BSD.] -- Dan_Jacobson@ATT.COM Naperville IL USA +1 708 979 6364
mcohen@amsaa-cleo.brl.mil (Marty Cohen) (03/13/91)
Many of us are daily users of vi, but still aren't comfortable
enough to use features like multifile editing. Would some expert
please give a short example of editing three files and moving text
from one to another?
--
--
Marty Cohen mcohen@brl.mil {uunet|rutgers}!brl!mcohen
Custom House Rm 800, Phila. PA 19106 (215)597-8377peter@ficc.ferranti.com (Peter da Silva) (03/13/91)
In article <2251@borg.cs.unc.edu> leech@vangogh.cs.unc.edu (Jonathan Leech) writes: > RSX-11 I know from nothing, but VMS subprocesses are generally > nicer for shell escapes - er, DCL escapes - than Unix. SUSPENDing the > subprocess and returning to the editor preserves the context of > whatever you were doing in the next shell escape, which can be useful. Of course this means the editor doesn't know about your escape. VI at least remembers your last shell command. Of course with layers/ptys/etc there's no problem getting the VMS behaviour in UNIX so it's a moot point. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
meissner@osf.org (Michael Meissner) (03/14/91)
In article <1991Mar12.190344.7863@ecf.utoronto.ca> xiaoy@ecf.toronto.edu (XIAO Yan) writes: | In article <MEISSNER.91Mar12115840@curley.osf.org> meissner@osf.org (Michael Meissner) writes: | (lines deleted...) | >However, vi only gives you one alternate file, so if you have more | >than 2 files, you lose. | | (lines deleted...) | | Are you serious? | Or are you using some pecular programme calling itself vi? | Or you are insulting our intelligence!! By losing, I meant that the vi(le) editor only keeps track of the current position for the current file, and the alternate file. It does not keep track of the position you were at for all of the files in the edit list. Also, keeping track of which file I'm in a sequence of files is for the birds, as is having only alternate file. Even without considering the other features, this was a powerful reason for me to switch to emacs (CCA originally, and now GNU). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
tchrist@convex.COM (Tom Christiansen) (03/14/91)
From the keyboard of mcohen@amsaa-cleo.brl.mil (Marty Cohen):
:Many of us are daily users of vi, but still aren't comfortable
:enough to use features like multifile editing. Would some expert
:please give a short example of editing three files and moving text
:from one to another?
You use the named buffers. There are a-z; use "a to access them
for use with the yank, put, and delete commands. Capital letters
append to the buffers, lower-case will overwrite. Let's say we
want to edit the files foo, bar, and baz. Do this:
$ vi foo bar baz
/some_string # find some string
"ad) # delete next sentence into named buffer a
:n +/ # go on to next file. assume autowrite set;
start at some_string (i have ^N bound to this)
{"Ay2} # back up previous paragraph, yank next 2 paragraphs
into named buffer a, appending to what was there
/other_string # find something else
"bdG # delete from there to bottom of file
into named buffer b
:n # go to next file
/omega # find a string
"aP # insert things from named buffer a before
cursor position.
G"bp # go to bottom of file, put what's in named buffer
b after cursor
:rew # go back to first file and iterate until happy
Note that your named buffers, including the numeric ones, stick around
between files, but the unnamed buffer gets trashed.
The numeric buffers are your delete stack. "3p will put the third-
to-the-last thing back. The dot command is special for numeric
buffer references: it autoincrements them. This allows you to
run backwards through your delete stack by just hitting a dot.
For example, this will reverse a list of 6 lines in your file:
dd # delete this line
..... # repeat 5 times
k"1p # go up and put back last line deleted
..... # repeat with autoincrement, reversing lines
--tomtorek@elf.ee.lbl.gov (Chris Torek) (03/18/91)
[Note, there is an important observation at the end.] In article <1991Feb22.134323.20410@scrumpy@.bnr.ca> bnrmtl!lewis@larry.mcrcim.mcgill.edu writes: > a) Strict window on file: just as it is in general not possible to see all > lines of a file, I also don't need to see all columns. I don't like > editors that wrap lines. GNU and Unipress Emacs (and others) have this as an option; vi does not. > b) Editor automatically strips trailing blanks (they can't be seen so they > should not exist). Easy to program in Emacs, somewhat uglier in vi. The magic vi command is :%s/[ ][ ]*$// (substitute on space-or-tab followed by zero or more space-or-tabs followed by end of line; replace with nothing). This can be mapped to a key sequence (including `ZZ'). This depends on the `magic' setting. > c) Tabs are expanded, again because they're invisible. This issue is a complete morass. There are many `kinds' of tabs: ASCII code 9, in files. What the terminal (or window or whatever) does with the above. What TAB key on the keyboard sends. What the editor does with the sequence the TAB key sends. No matter what you do with the ones you can set, someone will be unhappy. To be consistent, however, you must: 1. rule that ASCII 9 in files means `move to (col-1)%8+9'. [Note: columns here are numbered from 1 at the left, and `%' means `mod'.] 2. use the termcap/terminfo description to figure out what hte terminal does and accomodate it. You can then map user `tab' key sequences into anything you like. If, however, you map it to anything other than `insert one ASCII 9', you must make more decisions, about which someone will be upset. GNU and Unipress Emacs allow you to program whatever you like. For instance, in `picture mode' the cursor can go anywhere and appropriate whitespace will magically be created as necessary. Unfortunately, the magic whitespace is either: - all spaces: some people will complain, others will be happy; - minimal combination of spaces and tabs: same, but the two groups are reversed. Also, the magic whitespace (choose any or all of the following): - causes existing <tab or space> whitespace to be remapped to minimal <tab plus space> whitespace; - leaves existing <tab or space> whitespace alone; - automatically removes inserted magic whitespace; - always leaves inserted magic whitespace behind; - removes magic whitespace conditionally; - <any other possibility you can think of>; and no matter which you choose, someone will claim it is wrong. vi does not (quite) let you program a picture mode since you cannot tell whether <number>| will move to the given column, or will land on a tab and move to column number (<number>-1)%8+8. > d) Non-modal. Ill defined; `mode' means too many different things. In any case, Emacsen generally allow you to be nonmodal without requiring it, but make it hard to be `modal' in the style of vi and encourage you to have `file modes' (tab does different things when editing .el files vs .c files, e.g.). Since Emacsen are generally programmable, you can do anything you want here. > In addition, another thing I want (and which frustrates me no end on vi) > is total freedom of movement in the window and automatic scrolling when > cursor hits a border. Can be done in most Emacsen. > On the display, I like a status line and expect a command line. Can be done in most Emacsen, although the `status line' may require a blank line above it (though you could use that for your `command line') and may always be highlighted. >2) Editing keys > > This is a controversial topic. No kidding. :-) > What I prefer (although I recognize it limits range of terminals) is > keypad for general positioning (page down/up, next file, insert/replace > mode) and c-keys (or alt keys on a PC) for editing (c-y for yank, c-r for > repeat line, c-x for delete &c). Use of a keypad is typical of VAX/VMS > editors (EDT, EVE) for example. I see two user modes when using an editor, > browse mode (looking for stuff) and edit mode. (You just said you did not like modes. See what I mean about `modal' having different meanings? Here it means `the user's brain mode' and not `the editor's key-action mode'.) In any case, both vi and Emacsen can do this, provided you are willing to `limit [your] range of terminals'. vi has more trouble since it tends to be in `insert mode' or `edit mode' (you have to make heavy use of map and map!, and some mappings are impossible---more on that in a later article). >3) Essential features: > > - EASY TO LEARN and as INTUITIVE as possible. `Intuitive' is undefined. Intuitive to Joe may be gobbledygook to Jane, and vice versa. >An editor that comes with 300 pages of documentation is NOT easy to learn. This is the price of extreme flexibility (Emacs). It is, however, not necessary (and is often undesirable) to give everyone the complete documentation. People who are frightened by documentation length may be given a `dumbed down' configuration and manual. >SMALL is beautiful also applies (i.e. you shouldn't need one meg to edit >an hello-world program). Well, that lets GNU Emacs out :-) . > - Basic features: insert/edit, Modes again! >intelligent split/join, vi has the latter, Emacsen can do both. >search/replace, (he means `without regular expressions' here:) Emacs has this, vi requires `set nomagic'. >delete lines, yank lines and the like. Everything has this. >Autoindenting of new lines. vi has this in limited form (`autoindent', `shiftwidth', and ^T/^D); Emacsen of course can do anything here. > Support for non-printing characters (such as FFs, ESCs, TABs if kept) > that may be in file. Unclear: `support' as in `leave them there but do not show them', or as in `allow them to be added/removed', or `show them in inverse video', or `show them in control notation ^K', or...? There is an almost infinite variety of ways to handle this. vi gives you one; Emacsen generally give you two. > - Multiple (at least 2!) files simultaneously with of course possibility > to move stuff from one to another. vi can do this, albeit painfully. Easy in most Emacsen. >Typically organized in a ring. The files are in a ring? (makes no sense.) > Should be able to name multiple files on command line, e.g. ed *.c. Everything does this. > - Block operations (moving groups of lines for example). PE2's block > operations are really good (blocks can be lines, streams, rectangles). vi has this in somewhat limited form (blocks are `sentences/paragraphs/ marked lines/marked streams'); Emacsen can do anything (including rectangles: see picture mode). > - Undo or (at a minimum) recover facility. vi has this in somewhat broken form (U is line undo, breaks if you move off the line; little-u undo fails after complicated macros). Emacsen have undo. Both can recover, if by this you mean `bring the file back in' (:e! in vi, read-file in Emacsen). > - Protection against destructive writes. For example, vi allows the > following: user1 and user2 are both editing the same file. User1 > saves his work and then user2 saves his work thereby destroying > user1's work (this latter save should be refused because the file is > no longer the same as when it was read in). A few vi variants have this, most Emacsen do. >4) Very useful features: > > - Multiple (at least 2) views simultaneously of same/different files. vi had this, then Bill Joy lost all his work when the disk crashed, because the backup device was broken (this back in 197x). Since then no one has done it again. vi's internal structure (or lack thereof) makes it very difficult. Emacsen of course have it. > - Access to system (shell) without quitting editor. In particular, > possibility to pipe the output of a command into the editor (in a new > "file", e.g. <ls -l), or to pipe the current file into a command (e.g. > >diff - orig.file). Or even both together, to filter a file. Maybe > this belongs in the previous section (at least in part). Every sane Unix editor has this (vi and all Emacsen included). > - Autosave or some other mechanism to prevent complete loss of a session > on power failure. vi has `vi -r', Emacsen generally checkpoint. > - RE searching: at the risk of shocking a lot of readers, I'll say that I > don't find this very useful (except in ed scripts and the like). Most programmers will never give them up. vi has magic/nomagic (kludgy since it cannot be saved & restored in macros); most Emacsen have plain and `regular expression' operations as separate entities, and you are free to use either or both (I use both, with `plain search' as my default, in my own private version of Emacs). > - Right/left shift of groups of lines as when adding an if statement around > a bit of code. vi and Emacsen have this. > - Marks (e.g. to quickly return to a given spot), direct line addressing. vi and Emacsen have this. > - Macros. Or learn mode. vi and Emacsen have macros (in vi, macros are the only extension mechanism); Emacsen have learn mode. > - A minimum of WP features: word wrap and paragraph reflow are very > useful (as in PE2), particularly for e-mail. I'd even add spell > checking to the nice-to-have features. Emacsen have this. vi allows piping through external programs to do it; the `fmt' program (comes with BSD, available elsewhere) does the `reflow'. > - Adjustable window size (for xterms). Emacsen have this. Some versions of vi have this, with concomitant bugs. Having put this into my own private Emacs, I will attest that it is very difficult to do this right. >5) Nice-to-have features: > > - Hex editing/viewing. The viewing is the more useful of the two. Not sure exactly what this means, but since Emacsen and vi have filter capabilities, you can always turn the file into hex, edit/view, then turn it back into regular data. > - Line exclusion (possibility to exclude a group of lines from being > displayed - useful to better see a complex structure, e.g. by hiding > uninteresting code that clutters a switch statement). vi cannot do this, and many Emacsen (including mine) cannot. I believe GNU Emacs can. > - Sort feature. First met this on CMS's XEDIT and find it very useful > in all sorts of situations (not only for acronym lists). Just sort the file (use the filter capability if you prefer). > - Many people would name redefinable keys as a worthwhile feature. I > find it's more of a nuisance than fixed definitions. If they are not redefinable, it is impossible to use keypads, because every keypad has a different setup. >6) Other observations > > - In general (but not for word processors), I prefer an editor that is > line-oriented as opposed to character-oriented. vi does both, for just about everything. Emacsen do characters but it is easy to program them to select whole lines as their character ranges. > - I don't personally like an editor that jumps around to show me () > matching and the like. If it's available, I want to be able to turn it > off. I tend to write the two together and then insert within. vi and Emacsen all have options. > - Guess-typing by the editor (I seem to have heard of that at one point) > would drive me insane because it would force me to continuously control > what's going on. I have no idea what this means. And last, the important observation: Although most Emacsen can be programmed to do anything you want, it generally turns out that those who are willing to learn what it takes to do this are not the ones that want to reconfigure the editor. (There are some notable exceptions.) The trick is that a dumbed-down Emacs (wired to `editing policy X') can be written, but to do it you have to learn how, and by that time there is no longer any reason to do it. Thus, to get a dumbed-down version for N people, at least one person must first learn how to really use the editor. At that point the one person generally no longer wants to create and document the dumbed-down version: she would rather teach the others how to use it (`because all this stuff is so *useful*'!). The only way to bootstrap, in other words, is to commit someone to it as a special project. Universities generally do not have the resources to spare, and corporations generally have the money to just buy something else. Hence there are few, if any, programs for Emacsen that wire them into some particular editing policy. There are plenty that `almost work', written as an exercise, but they are usually not good enough to be used by those people who complain about Emacsen being `too complicated'. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
Dan_Jacobson@ATT.COM (03/21/91)
>>>>> On 17 Mar 91 20:41:39 GMT, torek@elf.ee.lbl.gov (Chris Torek) said: Chris> In article <1991Feb22.134323.20410@scrumpy@.bnr.ca> Chris> bnrmtl!lewis@larry.mcrcim.mcgill.edu writes: > - Guess-typing by the editor (I seem to have heard of that at one point) > would drive me insane because it would force me to continuously control > what's going on. Chris> I have no idea what this means. Maybe this GNU Emacs feature: ---- dabbrev-expand: ESC / Expand previous word "dynamically". Expands to the most recent, preceding word for which this is a prefix. If no suitable preceding word is found, words following point are considered. [...] If the cursor has not moved from the end of the previous expansion and no argument is given, replace the previously-made expansion with the next possible expansion not yet tried. ---- Also there's ispell-complete-word: Complete word at or before point [Part of the ispell add-on package for GNU Emacs], pops up a buffer of possible endings of the word to type in for you. You select one. ---- Or probably he meant GNU Emacs' abbrev-mode. "In abbrev mode, inserting an abbreviation causes it to expand and be replaced by its expansion." There are several pages of explanation of this in the manual. -- Dan_Jacobson@ATT.COM Naperville IL USA +1 708 979 6364
lewis@bnrmtl.bnr.ca (Pierre Lewis) (03/21/91)
In article <11032@dog.ee.lbl.gov>, torek@elf.ee.lbl.gov (Chris Torek) replied to my initial post. There were many good points in his reply (and I guess I need to rework my ideas a bit to clarify them!). With this list (and a few others I got thru e-mail) I have a very clear picture of the extent to which vi or emacs fill my wish list (note that I never meant to suggest that they didn't; for example, as Chris says, all decent Unix editors can pipe in and out of the editor and I expected that both vi and emacs are capable of this). On the topic of TABS. > This issue is a complete morass. > No matter what you do with the ones you can set, someone will be unhappy. > You can then map user `tab' key sequences into anything you like. If, > however, you map it to anything other than `insert one ASCII 9', you > must make more decisions, about which someone will be upset. > and no matter which you choose, someone will claim it is wrong. Exactly what I observe. That's why, at least, I avoid tabs in files. Of course the editor should make use of the key somehow (it's on every terminal). A complete editor should, I suppose, give all the options. On the concept of non-MODAL. > Ill defined; `mode' means too many different things. Agreed. What I don't like in vi is that the editor (as opposed to my brain over which I have somewhat better control) can be in different modes with the cursor in the text area and I can't seem to remember which one and can't tell from just looking at the display (it looks exactly the same whether one is in insert mode or in command mode). > (You just said you did not like modes. See what I mean about `modal' > having different meanings? Here it means `the user's brain mode' and > not `the editor's key-action mode'.) Right again, and I do mean user brain mode here! And there are more modes (insert/replace, etc.) to come! On INTUITION. > `Intuitive' is undefined. Intuitive to Joe may be gobbledygook to Jane, > and vice versa. Of course, and that's why there will never be any single editor to please everyone. I should define this more carefully, but I'm not sure I can! As a first attempt, it's when I can guess without having to read the documentation. If for example the key to split lines is C-S maybe I'll guess it. If it's ESC C-Y C-Q META-F1 there's no chance! On SIZE. > >SMALL is beautiful also applies (i.e. you shouldn't need one meg to edit > >an hello-world program). > > Well, that lets GNU Emacs out :-) . I've just been told emacs stands for Eight Megs And Constantly Swapping :-). Surely not new to most readers but we had a good laugh here. XEDIT also would probably not rate (I have no clue how big it is, but it can't be small). On NON-PRINTING support. > > Support for non-printing characters (such as FFs, ESCs, TABs if kept) > > that may be in file. What I mean is being able to add/remove them from file. Of course they have to be made visible somehow. The way vi does this is fine (except for tabs cause I don't see them - but maybe this can be changed); with emacs I don't know what it looks like, but I'm sure it's fine too. On RINGS. > The files are in a ring? (makes no sense.) This is an XEDIT concept, it means simply +--> file A ---> file B ---+ that the files are organized in a ring: | | (and a single keystroke typically +--- file C <--- file D <--+ moves you from one file to the next) > > Should be able to name multiple files on command line, e.g. ed *.c. > > Everything does this. Well not on MS-DOS unless I'm really out of it. And why does mail start up n editors when I type "v 1-5" instead of just one editor if all editors do this (well, true, it would have to create many temporary files)? On UNDO and RECOVER. > Both can recover, if by this you mean `bring the file back in' > (:e! in vi, read-file in Emacsen). No I mean have access somehow to original status of modified/deleted lines. Both XEDIT and PE2 have something of this type. A full undo is of course much, much better. On WP FEATURES. > Vi allows piping through external programs to do it; That's fine, but what if I only want to reflow a single paragraph, not the whole file. I guess I move the paragraph to another file, filter it, bring it back. PE2 will let you reflow your paragraph with a single keystroke, emacs too I understand. The same applies to sorting. What if I want to sort only part of the file. In XEDIT, a single command will do it. On HEX EDIT. > Not sure exactly what this means, but since Emacsen and vi have filter > capabilities, you can always turn the file into hex, edit/view, then > turn it back into regular data. True, but a real hex editor is a joy to work with when you must edit binary files (rare, it's just a nice-to-have and hence above mechanism is generally satisfactory). Here's an example of the display with such an editor: 000000: 50617468 3A20626E 726D746C 40626E72 *Path: bnrmtl@bnr* 000010: 2E636121 6C657769 730A4E65 77736772 *.ca!lewis.Newsgr* 000020: 6F757073 3A20636F 6D702E65 6469746F *oups: comp.edito* If I now search for /Newsgroups/ a real hex editor will find it. On REDEFINABLE keys. > If they are not redefinable, it is impossible to use keypads, because > every keypad has a different setup. Good point. The only way this could work is if you restrict the terminals or do the mapping outside the editor (as I do with xterm, via .xresources). And in CONCLUSION... > And last, the important observation: > > Although most Emacsen can be programmed to do anything you want, it > generally turns out that those who are willing to learn what it takes > to do this are not the ones that want to reconfigure the editor. > (There are some notable exceptions.) The trick is that a dumbed-down > Emacs (wired to `editing policy X') can be written, but to do it you > have to learn how, and by that time there is no longer any reason to do > it. ..... Good point. Isn't that the problem with all powerful editors, emacs, XEDIT, etc.? Thank you very much for all your comments! It'll force me to clarify my ideas further... (but no, I'm not planning to repost them!) -- Pierre LEWIS Internet: bnrmtl!lewis@Larry.McRCIM.McGill.EDU
tchrist@convex.COM (Tom Christiansen) (03/21/91)
From the keyboard of bnrmtl!lewis@larry.mcrcim.mcgill.edu: |Agreed. What I don't like in vi is that the editor (as opposed to my brain |over which I have somewhat better control) can be in different modes with the |cursor in the text area and I can't seem to remember which one and can't tell |from just looking at the display (it looks exactly the same whether one is in |insert mode or in command mode). :set showinsert :set si most modern vi's support showinsert to avoid this. i never use it myself, as it annoys me, but beginning users seem to like it. i'm used to typing esc if i'm unsure. |Of course, and that's why there will never be any single editor to please |everyone. I should define this more carefully, but I'm not sure I can! |As a first attempt, it's when I can guess without having to read the |documentation. If for example the key to split lines is C-S maybe I'll guess |it. If it's ESC C-Y C-Q META-F1 there's no chance! exactly -- there are far more possible commmands then mnemonic keystrokes. |What I mean is being able to add/remove them from file. Of course they have |to be made visible somehow. The way vi does this is fine (except for tabs |cause I don't see them - but maybe this can be changed); with emacs I don't |know what it looks like, but I'm sure it's fine too. :set list This displays tabs as ^I and EOL as $. |> The files are in a ring? (makes no sense.) | |This is an XEDIT concept, it means simply +--> file A ---> file B ---+ |that the files are organized in a ring: | | |(and a single keystroke typically +--- file C <--- file D <--+ |moves you from one file to the next) That's why I bind ^N to be ":n +/". Then ^N goes to the next file. With autowrite and write any set, it works well. |Well not on MS-DOS unless I'm really out of it. And why does mail start up |n editors when I type "v 1-5" instead of just one editor if all editors do |this (well, true, it would have to create many temporary files)? sounds like mail's fault. |> Both can recover, if by this you mean `bring the file back in' |> (:e! in vi, read-file in Emacsen). | |No I mean have access somehow to original status of modified/deleted lines. |Both XEDIT and PE2 have something of this type. A full undo is of course |much, much better. for each line? |> Vi allows piping through external programs to do it; | |That's fine, but what if I only want to reflow a single paragraph, not the |whole file. I guess I move the paragraph to another file, filter it, bring |it back. PE2 will let you reflow your paragraph with a single keystroke, |emacs too I understand. You can do a filter-region instead of the whole file. :map = {!}fmt^M |The same applies to sorting. What if I want to sort only part of the file. |In XEDIT, a single command will do it. ditto. name your region with marks or by targets, and send it through your favorite sort with a !sort -rn kind of command. this shouldn't be built into your editors. --tom
tchrist@convex.COM (Tom Christiansen) (03/21/91)
From the keyboard of torek@elf.ee.lbl.gov (Chris Torek):
:This is fixed in 10th Edition Unix. It is just an accident of history.
:There *is* a reason for some difference, actually: Editors must have
:a way of marking matches for substitutions, while pure matchers (grep)
:do not need this.
Untrue. I use \references on the LHS of my substitutes, albeit
infrequently. For example:
prep '(\w+)\s+\1' *.ms
to find repeated words on the same line in a document.
--tom
ps: prep basically works out to be an alias like this:
alias prep "perl -ne 'print if /$^/' \!:2-$"
accept I don't require the filenames. In straight egrep, you would say:
egrep '([a-zA-Z0-9_]+)[ ^I]+\1' *.ms
In grep it's more cumbersome still for lack of + operator. Perl regexps
have some other nice properties, too, but I won't get into that here.
Anybody got a good way of doing "word-boundaries" in egrep? In grep
you can use -w, but only gnu's egrep takes it. I use \b in perl, \<
in vi, but egrep is a pain for this. Well, that's what the prep alias
is for I guess.
--tomtorek@elf.ee.lbl.gov (Chris Torek) (03/21/91)
In article <1991Mar20.191434.5634@scrumpy@.bnr.ca> bnrmtl!lewis@larry.mcrcim.mcgill.edu writes: [`non printing characters'] >What I mean is being able to add/remove them from file. Of course they have >to be made visible somehow. The way vi does this is fine (except for tabs >cause I don't see them - but maybe this can be changed); with emacs I don't >know what it looks like, but I'm sure it's fine too. I will not attempt to guess how different Emacsen handle tabs (my own private version makes them `tab to column-mod-n' where n can be set on a per file basis; if you set n to zero or negative, tabs are just another control character). Vi has something called `list' mode in which tabs are shown as ^I: :set list turns this on, and :set nolist turns it off. In list mode end-of-line is also signified as `$'. [rings] >This is an XEDIT concept, it means simply +--> file A ---> file B ---+ >that the files are organized in a ring: | | >(and a single keystroke typically +--- file C <--- file D <--+ >moves you from one file to the next) Ah: in Emacs you just bring up ten zillion windows and select amongst them any way you like. In vi, `:n' (or :next) goes to the next file. There is no convenient way to back up (control-^ or :e# switches to the `current alternate file', which is the previous file after a :n, but you cannot get any further back than that). When you reach the end, or want to restart, `:rew' (:rewind) takes you back to the first. At any time, :args will show the arguments with [] around the current file. >>> Should be able to name multiple files on command line, e.g. ed *.c. >> Everything does this. >Well not on MS-DOS unless I'm really out of it. I guess I should have said `Every sane Unix editor'---VMS EDT apparently also does not. >[why does mail start one editor per file] This is the fault of whoever wrote mail; >(well, true, it would have to create many temporary files)? this is a likely reason. >> Vi allows piping through external programs to [fill lines] > >That's fine, but what if I only want to reflow a single paragraph, not the >whole file. You type {!}fmt and hit return: { means `move back a paragraph' (i.e., to the beginning of this one), ! means `filter' (pipe), } means `move forward a paragraph', and fmt is the `external program' that does it. If you like, map #1 {!}fmt^M in a .exrc or EXINIT will bind `function key 1' (if it exists, and is described in termcap) to this. One problem with this, again, is vi's limited understanding of `paragraph' (trailing whitespace on a blank line means that line does not separate paragraphs). One thing missing from some non-Unix editors is `tags': vi and Emacsen generally have the notion of a `tags file', which contains the names and `locators' for things in a program. Typing `:tag foo' means `find the tag for foo', and ^] means `find the tag for the word under the cursor' (in vi; Emacs tags generally are somewhat different). Tags are mainly useful for navigating around large programs. Tags locators are regular expressions, rather than line numbers, so that most changes to the source do not outdate them. Many vi tags implementations have an annoying bug: selecting a tag that appears in the current file fails if you have `nowrapscan' set and the tag appears before the current cursor position. This is easily fixed in the source: just save and restore nowrapscan, and turn it off for the tag search. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
les@chinet.chi.il.us (Leslie Mikesell) (03/21/91)
In article <1991Mar20.191434.5634@scrumpy@.bnr.ca> bnrmtl!lewis@larry.mcrcim.mcgill.edu writes: >On the topic of TABS. >Exactly what I observe. That's why, at least, I avoid tabs in files. Of >course the editor should make use of the key somehow (it's on every terminal). >A complete editor should, I suppose, give all the options. If you intend to edit Makefiles, you probably want to store real tabs in the file. >On the concept of non-MODAL. >Agreed. What I don't like in vi is that the editor (as opposed to my brain >over which I have somewhat better control) can be in different modes with the >cursor in the text area and I can't seem to remember which one and can't tell >from just looking at the display (it looks exactly the same whether one is in >insert mode or in command mode). Current vi's have ":set showmode" to display the mode on the bottom screen line, but it's kind of annoying. I happen to like vi's modal operation, although it did take a long time to get used to it. I tend to view, browse, and search much more text than I actually modify or insert. Being in command mode by default with most commands available on the "handy" parts of the keyboard makes this much easier. Also, if you prepend an ESC to each of the normal vi commands you would notice that the only remaining concept of modedness is that you have to explicitly start an insert or append. Everything else then works the same no matter what mode you were in, since an extra ESC in command mode is ignored (except for the beep). BTW, this is the worst problem I have with VIP-mode in GNU emacs - ESC ESC does something very different than vi. >On INTUITION. >Of course, and that's why there will never be any single editor to please >everyone. I should define this more carefully, but I'm not sure I can! >As a first attempt, it's when I can guess without having to read the >documentation. If for example the key to split lines is C-S maybe I'll guess >it. If it's ESC C-Y C-Q META-F1 there's no chance! All the same to me... And if by C-S you mean control-S, please save everyone a lot of trouble and avoid using common flow control characters that won't pass through a lot of communications links as editor commands. >On UNDO and RECOVER. There is a subtle connection between undo/repeat and modedness. If you don't have explicit commands to start and stop insert and append modes, undo and repeat commands won't have boundaries for these operations. >On WP FEATURES. [re-wrap by filtering] >That's fine, but what if I only want to reflow a single paragraph, not the >whole file. I guess I move the paragraph to another file, filter it, bring >it back. No, you can filter a limited region through another process, but I agree that re-wrap should be built in, since it is simple (wrapmargin is already there) and it is common. >The same applies to sorting. What if I want to sort only part of the file. >In XEDIT, a single command will do it. I wouldn't want this built into an editor unless it provided everthing you might want in a sort - kind of at odds with your "small is beautiful" comment. On the other hand, I've found the sort in Wordperfect to be quite useful on DOS systems where you don't have a good external sort program. It's also nice that it knows to ignore its own formatting codes and knows how to deal with elements of it's mail merge lists. Les Mikesell les@chinet.chi.il.us
peter@ficc.ferranti.com (Peter da Silva) (03/22/91)
In article <1991Mar20.191434.5634@scrumpy@.bnr.ca> bnrmtl!lewis@larry.mcrcim.mcgill.edu writes: > > No matter what you do with the ones you can set, someone will be unhappy. > Exactly what I observe. That's why, at least, I avoid tabs in files. That makes *me* unhappy. I get code like that, it goes through indent straight off. > That's fine, but what if I only want to reflow a single paragraph, not the > whole file. {!}fmt You can pipe any part of the file through an external program and put it back. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
torek@elf.ee.lbl.gov (Chris Torek) (03/22/91)
In article <1991Mar20.203401.26237@convex.com> tchrist@convex.COM (Tom Christiansen) writes: [in reply to my statement that `pure matchers' do not need \(...\)-style `remember' expressions] >Untrue. I use \references on the LHS of my substitutes, albeit >infrequently. For example: > > prep '(\w+)\s+\1' *.ms > >to find repeated words on the same line in a document. Such references are, strictly speaking, not regular expressions at all. I will not deny their utility, but they do make building a matcher more difficult, which is why egrep, e.g., does not support this. (Egrep builds a DFSA and then runs it, and egrep DFSAs cannot be made to perform backreferences.) The only reason I made the note in the first place was to prevent someone else from objecting to the `same syntax for editor and matcher' idea with the same note. In other words, I was anticipating the claim: `using the same syntax is stupid because ...' and had already rejected it. I take it this was unclear in my original article.... -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
lewis@bnrmtl.bnr.ca (Pierre Lewis) (03/26/91)
Little did I expect, when I submitted my original post, that I would learn
more about vi and emacs (esp. the former) than I ever learned from all other
sources. Thanks to all for the pointers. Even if I don't use vi often, I
do use it at times and this is useful information.
On intuitivity...
Yes the C-S example was not so great because it's used as a flow control
character. Here are two hopefully better examples of what I mean by
intuitive. For lack of a real definition.
1) vi commands :w :q and :n
With the vi on our SunOS 4.0.3, I can do the following:
:w to write back a file
:q to quit the editor
:wq to write back a file AND quit the editor
I can also do:
:n to move to next file (if current file has no pending changes)
So I thought, given previous experience with :wq (which seemed to indicate
that you can concatenate commands), that
:wn to write back a file AND move to next file
would also be possible. Filled with blind faith (on one occasion where
I happened to be cleaning up a few uuencoded files), I tried (after
editing first file):
:wn
and got the message "wn: Not an editor command". There is surely some
other command that will do it, but why not the intuitive choice?
Here's one case where an editor failed to be intuitive. Anyone can give
me a good reason why ":wn" should not work if ":wq" works?
2) XEDIT command show
With XEDIT, it is possible to exclude some lines from the display (e.g.
to hide some error processing which we are not momentarily interested
in). A very useful feature, maximizing information on display. For
example, the display might look like:
===== if (! (pfcb = (tFcb *)malloc(sizeof (tFcb)))) /* alloc fcb */
===== {
===== ----------------- 6 line(s) not displayed -----------------
===== }
===== else memset(pfcb, 0, sizeof(tFcb));
At this point, it is possible to enter in the prefix area (the command
area in front of a line) the command "s" to make the hidden lines all
visible again. Or the command "s3" to make only the first three visible
again. But what if one wants to make the LAST three visible. The first
thing that came to my mind (I did have quite a bit of experience with the
editor, but I don't know of any other prefix command where this might be
useful) is "s-3". I tried it
s-3== ----------------- 6 line(s) not displayed -----------------
and it worked as expected. That an example of an editor being intuitive.
--
Pierre LEWIS
Internet: bnrmtl!lewis@Larry.McRCIM.McGill.EDU
Lubarsky's law of cybernetic entomology: There is always one more bug!phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (03/27/91)
> b) Editor automatically strips trailing blanks (they can't be seen so they > should not exist). How about making it so they are visible. > c) Tabs are expanded, again because they're invisible. You mean when I write the file out there are no longer any tabs in it? How about an editor that makes them visibly different? > - EASY TO LEARN and as INTUITIVE as possible. Emacs as easy to learn and intuitive to emacs users. Vi is east to learn and intuitive to vi users. Which are you? (I need to know to know which editor to tell you to use :-) >An editor that comes with 300 pages of documentation is NOT easy to learn. That depends on whether the documentation was written as a tutorial for the illiterate, or as a reference manual. In the latter case I might agree. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks / \***************************************************************************/
ch@dce.ie (Charles Bryant) (04/04/91)
In article <11200@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >One thing missing from some non-Unix editors is `tags': vi and Emacsen >generally have the notion of a `tags file', which contains the names >and `locators' for things in a program. Typing `:tag foo' means `find >the tag for foo', and ^] means `find the tag for the word under the cursor' >(in vi; Emacs tags generally are somewhat different). Tags are mainly >useful for navigating around large programs. > >Tags locators are regular expressions, rather than line numbers, so that >most changes to the source do not outdate them. Well they are actually *any* ex commands. For example the following line in a tags file: foo % !rm % will remove the file being edited when tag `foo' is searched for. Now if someone can point out how to use the output of such a command to go to a line, I could devise an entry that looked up the tag when selected instead of having a fixed table. [the command "r !echo 23|d z|@z" springs to mind, but "r !..." dosen't respect the ex command delimeters (|)] My colleague Eamonn McManus (in real life em@dce.ie) just pointed out that the ability to run commands via tags is yet another feature to watch out for in a restricted environment. Incidentally, I noticed that: foo foo /foo/ foo % /foo/ are not the same (`%' expands to the current file name) even when foo is the current file. Vi knows that `foo' won't change the current file, but dosen't realize that `%' won't either. -- Charles Bryant (ch@dce.ie) -- If you like the opinions expressed in this message, they may be available for rent - contact your local sales office. Low interest deals available.