Xref: utzoo comp.misc:5500 comp.editors:537
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!tank!shamash!com50!pwcs!stag!trb
From: trb@stag.UUCP ( Todd Burkey )
Newsgroups: comp.misc,comp.editors
Subject: Re: UNIX needs a real text editor
Message-ID: <743@stag.UUCP>
Date: 14 Mar 89 15:55:42 GMT
References: <222@imspw6.UUCP> <252@torch.UUCP> <2112@mister-curious.sw.mcc.com>
Reply-To: trb@stag.UUCP ( Todd Burkey )
Organization: Mindtools ST Access Group, Plymouth, MN
Lines: 78

In article <2112@mister-curious.sw.mcc.com> loo@mister-curious.sw.mcc.com (Joel Loo) writes:
>
>[Comment: Programmability is a nice concept but don't stretch  it
>too  far.  I had the experience of spending more time programming
>an editor than on my work. One complaint about vi is that it  has
>modes.  My  view is that modeless editors are nice for beginners,
>but an old-hand doesn't even realize vi has modes;  modes  become
>natural  to  him. Use of the mouse is, again, nice for beginners,
>but I find it a pain when I was forced to use it in Smalltalk and
>Macintosh;  I just could not do cutting and pasting as fast as in
>vi (nothing to do with my agility, it is inherent  with  mice,  a
>lot of hackers will agree with me).]

I guess I qualify as a hacker and I do agree...up to a point. I use
vi, emacs (occasionally), micro-emacs, and Apollo DM edit in my normal
programming environment and I have used the Vax editors, various PC
and Atari ST editors, and lots of line editors in the past. In the
early days of Emacs, I was a 'macro' fanatic, even putting up with
the incredibly slow operation of emacs on my IBM PC just to have the
same macros running there. About 5 years ago, I found myself in an
environment that only had vi and I managed to become a vi addict with
very little kicking and screaming (maybe a years worth).

I agree that vi is better at single buffer cut and paste than emacs.
Vi doesn't have more capability in this area, it is just easier and
faster to do cutting and pasting than in emacs (yes, even than in the
various emacs vi emulation modes.) Unfortunately, vi doesn't handle
multiple buffers in a very usable way (almost as if multiple buffers
were an afterthought during the development of vi). I also feel that
the phrase "mice are nice, but my finger doesn't linger" is
appropriate for most editor operations...except some inter-buffer
operations on high resolution, multiple window displays.

>Agree that vi need to be improved.  There  are  certain  features
>that  should  be  included (maybe someone can look into this). My
>advice is: spend more time reading the vi  reference  manual.  Do
>not be discouraged from using it just because vi has cryptic com-
>mands. It serves most programming needs just too well.

For years I have waited for a better programming editor. I have seen
faster editors on the various PCs, some very well integrated editors
coming out with the C and OCCAM development packages on the Atari ST,
but nothing that really integrates the programmer into his development
environment in Unix. My idea of an ideal editor is one that 1) allows
multi-file editing with a clean and fast buffering scheme, 2) fully
supports folding, 3) allows the programmer to relate lines and words
and use these relationships in a hyper-text like manner (i.e. moving
back and forth between a program document and the appropriate lines
of code at the press of a few keys), 4) has configurations save and
restore modes (so you can get back to EXACTLY the same place you left
off editing the day before...with all buffer info intact), and 5) has
more intelligence built in (rather than interpreted in macros.

What a coincidence :-). Last November I started writing an editor in my
spare time, just to see how hard it would be to add a thought
processor-like folding concept to an editor. I wrote this editor from
scratch, partly to learn why editors act the way they do the hard way,
and partly because I had a feeling that the vi or emacs styles would
restrict or dictate the implementation of folding. This editor is now
in alpha test and will be distributed to the net if it is still
bug-free a month from now. The editor does have everything that is
currently on my wishlist (see above), but I still regard it as more
of a prototype. There are a lot of snazzy features that I would like
to add (or see added) to the editor to turn it into a real CASE tool,
but my editor will likely need some heavy optimization and maybe even
a core logic rewrite first.

How do other programmers/hackers out there feel about the need for
higher level programming editors/tools? Are you completely happy with
your current editor, so things like folding and inter-file
relationships aren't really of any foreseeable use? Is moded vs.
non-moded really the issue between editors, or is it non-programmable
vs. programmable, or does it simply boil down to the actual options
and commands you have available in an editor?

  -Todd Burkey
   trb@stag.UUCP
   or ... tburkey@eta.com