Newsgroups: comp.editors
Path: utzoo!utgpu!cunews!bnrgate!scrumpy!bnrmtl@bnr.ca!lewis
From: lewis@bnrmtl.bnr.ca (Pierre Lewis)
Subject: Re: One user's editor wish list
Message-ID: <1991Mar20.191434.5634@scrumpy@.bnr.ca>
Sender: news@scrumpy@.bnr.ca (USENET (SY))
Reply-To: bnrmtl!lewis@larry.mcrcim.mcgill.edu
Organization: Bell-Northern Research Montreal, Canada.
References: <1991Feb22.134323.20410@scrumpy@.bnr.ca> <11032@dog.ee.lbl.gov>
Date: Wed, 20 Mar 91 19:14:34 GMT

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
