Path: utzoo!attcan!utgpu!watmath!watcgl!bmacintyre
From: bmacintyre@watcgl.waterloo.edu (Blair MacIntyre)
Newsgroups: comp.sys.amiga
Subject: Re: vi versus emacs regexps?
Message-ID: <11074@watcgl.waterloo.edu>
Date: 15 Aug 89 13:27:30 GMT
References: <21646@louie.udel.EDU>
Reply-To: bmacintyre@watcgl.waterloo.edu (Blair MacIntyre)
Organization: UofW Computer Graphics Lab
Lines: 66

In article <21646@louie.udel.EDU> MROBINSON@wash-vax.bbn.com writes:
>reason I ask is that I've given some thought to the idea of having this kind of
>position specification model at the *character* level, rather than the line
>level as in vi, and building a (freely redistributable, of course) editor
>around this idea.  The position specification model is complete, and I have a
>fairly good idea about what I want the editor to do, and how I want to
>structure the code, and all, but is it worth the doing?  Is DME really the
>be-all and end-all of editors, or would someone actually be interested in this?

I'm interested, for one.  I have been toying with the idea of writing an
editor, for a variety of reasons.  I use DME exclusively ( thanx Matt! ) but 
there are some things I dislike about it ( sorry Matt! :-)  The big things
I am in the process of adding to it, since I don't have the time to write 
an editor.  In case anyone cares, the two things I'm adding are multiple
(semi-infinite level along the lines of the way Emacs does it, within the
bounds of the way DME handles input and line changes) undoing and regular 
expression searching/replacing.  I've got the undo almost working, 
the regexp stuff will follow quickly ( can you say _trivial_ boys and girls?  
Gooood ... of course, undo was supposed to be quick, since I've written in
before in another editor on Unix :-)

>Also, I've never written an editor before, and I was wondering if anyone has
>opinions about how an editor should handle memory, especially on the Amiga.
>Should the editor work on blocks of text, or just shove everything into one
>big buffer?  

Ok, there are two basic models that I can see:
 - an editor buffer (file) as a big "string" of text
 -  "  "      "       "    "  a collection of lines of text

I like the former way ( the way Emacs does it, the way the editor I worked
on did it ) but the latter is easier on a micro ( the way vi and DME do it ).
Of course, if you keep everything modular, it doesn't matter which way you
do it ( also makes some features _very_ easy to implement )  

I have lots of ideas on this, if anyone is interested ...

>And what special interface concerns have people noticed with
>editors?  Keymaps, raw keyboard input, color of the text, color of the cursor,
>clicking on text, multi-buffer windows versus multi-windowed editor, online
>help, mapping keys to commands, macros?

I like the DME interface and I like the Emacs interface.  I think that the 
best combo would allow you to have multiple windows, but would behave like 
Emacs in that any buffer could be displayed in any window interchangably.
Maximum generality is important in this case ... never say "no one would
use that feature" 

Do not do raw keyboard input, use the keymaps.  Again, generality.  
Things like colour should be up to the user.  On-line help is very important,
look at Emacs for a good implementation ...

Of course, everything should be user customizable, ala Emacs and DME.  This
is very important.  But, there should be reasonable defaults UNLIKE Emacs
(that's one thing I dislike about Emacs - not only is user customization
allowed, it is almost required! )

>Thanks for any input,
>  Max

Hey, no problem!
-- 
= Blair MacIntyre, bmacintyre@watcgl.{waterloo.edu, UWaterloo.ca}          // =
=   now appearing at the Computer Graphics Lab, U of Waterloo!           \X/  =
= "There's nothing the matter with BR that a shot gun blast wouldn't fix" cge =
= "It's not my fault, fatboy!" - Felder, pilot of TL Student Driver On Board  =