🚀 go-pugleaf

In article <1991Sep2.152330.726@csug.rdg.ac.uk> shrchin@rosemary.cs.reading.ac.uk (Jonathan H. N. Chin) writes:
>1. Does anyone use the `U' command?

Yes.

>2. Assuming the meaning of `u' is going to be changed, how do I
>   incorporate the redo operation, seeing as `r' is already taken
>   (hence Q1 above)? (Does anyone use the `r' command?)

`r' means `replace the character under the cursor with the next
character typed' and I use it constantly.  I'd be willing to sacrifice
U to mean `redo' if I was given multiple undo, because that'd basically
remove my need for U.

>3. What would be a clean way of incorporating rectangular region
>   handling into the command syntax? `d<move>' is the usual way
>   of deleting a region, so maybe we need to prepend a <rect> flag
>   somehow (ie. `d<rect><move>', maybe with `#' or `=' as <rect>;
>   `|' would be nice but `d|' defaults to deleting back to the start
>   of the line)?

I'd suggest revamping vi's targetting mechanism.  Instead of typing
d<target>, let the user type d<as many motion keys as the user wants>*
(since the * is unused in vi).  That would make deleting funny regions
much easier.  I'd do a lot less character counting if I could do that.
Then, for rectangular regions, you could use some other end-of-motion
key, like # (also unused).

Note that I consider myself a vi expert and a vi bigot; nevertheless, I
believe that vi could be improved and made much
friendlier/easier-for-beginners.

>4. What would be a suitable way of handling rectangular regions that
>   do not have enough text (eg:
>
>line1: col1 ... ...  col5
>line2: col1 ... col4
>line3: col1 ... ...  col5
>
>   where the desire is to operate on col4 and col5 of lines 1-3.)
>   Should the operation be flagged with an error and aborted, or
>   allowed, with the missing column filled in with spaces, or even
>   the missing column just ignored?

Offer an option of padding with spaces, or just ignoring the missing
columns.

>5. vi's syntax is fairly orthogonal, but the special cases are a
>   little confusing at times. Would it be worthwhile to clean it up
>   or would that just be even more confusing?

What special cases do you means?  Aside from the `cw' and `ce' which is
mentioned later in your article.

>6. vi commands to be changed? Little niggles like where the cursor
>   ends up after an operation. Why `~' can't be prefixed by a count
>   or even modified so that a <move> can be appended. An option to
>   allow all commands to be echoed.

You should make this a targetted command just like d or y or c, I
think.

>9. Finally, although I am not the world's greatest mouse fan, I allow
>   that they can make certain operations simpler. How could mouse use
>   be allowed without subsuming the functions that the operating system
>   provides (eg. windowing system, cut&paste, scrolling)? (Think of the
>   wonder of it - a vi that automatically resized itself when you changed
>   the size of your window! Or moving through your text using the
>   scroll-bar. (Bye-bye textedit!)) What interface should the editor
>   provide for mouse use? Obviously a plain DOS PC with no windows might
>   not have a mouse at all and neither would a tvi912.

I'd say offering a scrollbar would be a good idea.  Also, let the user
select text with the mouse, and then press one of the targetting
commands (like d or y or c) and have the command implicitly use the
highlighted text.  Allow clicking in the window to reposition the
cursor.  If a user `y's or `d's text, stuff it into the X window system
PRIMARY selection as if it had been `copied' or `cut'.  Let your editor
have its own window under X, and let it open multiple editing windows,
so that only one instance of the program needs to be running.  Have an
interface in your program so that if a copy of it is already running
and another copy is invoked, it simply tells that first copy to open a
new window editing the new file.  GNU Emacs and `iedit' (an editor that
uses the InterViews toolkit) have this functionality.

>Why does `cw' not behave as one would intuitively expect?

Probably because the author of vi (Bill Joy, I believe) felt that
having `cw' change to the end of the current word instead of to the
beginning of the next one would be more intuitive and friendly.  I
agree with you, especially since `ce' already gives that
functionality.

>But seriously, say I `:map z f' and then `:map f F' why does the `z' mapping
>disappear? Why doesn't it remember the operation the f originally was mapped
>to? (This is one of the short-comings I want to fix with my editor).

You probably have the remap option set.  Try :se noremap and see what
happens.  The question you must answer when considering this sort of
thing is how close you want your editor command set to be to a full
programming language.  Should keystrokes be like function calls, so
that if you make a macro, it's like a function that makes a series of
function calls, and if those functions have been redefined, use the new
definitions?  Do you want to offer a full programming language for
writing macros - conditionals, loops, etc?

rob

In article <1991Sep2.152330.726@csug.rdg.ac.uk>, shrchin@rosemary.cs.reading.ac.uk (Jonathan H. N. Chin) writes:
|>
|> Some questions:
|>
|> 1. Does anyone use the `U' command?

Yes, quite often. A line of C source code can easily be commented out and
back again. Often used in debugging "portable" sources.

Malte

shrchin@rosemary.cs.reading.ac.uk (Jonathan H. N. Chin) writes about a
vi-enhanced-clone, and I respond here since I would like others' input.

:I am in the process of designing (if that is the right word to use)
:a `text' editor. It will effectively be an extended vi clone. I plan
:to implement most of the features of vi with the exception of :(I don't know nothing 'bout lisp) and also those of ex, once I can
:resolve the ambiguities in the documentation I have.
:Some additions I want to make:
:
:- multiple undo/redo
:- rectangular region manipulation
:- macros that take arguments
:- 8 bit clean (ie. can handle binary files if desired, also foreign
:  character sets, IBM PC graphics, etc)
:- operations distinct from their key bindings (ie. can remap a key to
:  perform an operation that includes, as part of it, the initial
:  operation that the key defined)
:- unlimited line/file lengths

:1. Does anyone use the `U' command?

I do, but only occasionally, and if I could multiple-undo I could
probably often use that instead of the undo-all function of `U'.

:2. Assuming the meaning of `u' is going to be changed, how do I
:   incorporate the redo operation, seeing as `r' is already taken
:   (hence Q1 above)? (Does anyone use the `r' command?)

`r' is VERY heavily used.  I guess redo, a rarely used command, would
be nice to map to <negative number>-undo, if only there WAS a way to
prefix *negative* number (a nice idea in general, I believe...).

:3. What would be a clean way of incorporating rectangular region
:   handling into the command syntax? `d<move>' is the usual way
:   of deleting a region, so maybe we need to prepend a <rect> flag
:   somehow (ie. `d<rect><move>', maybe with `#' or `=' as <rect>;
:   `|' would be nice but `d|' defaults to deleting back to the start
:   of the line)?

I vote for '#<move>' to mean rectangular region, as opposed to
straight '<move>' meaning stream-of-text; this, however, leaves no
simple way to express 'three lines down AND 20 chars to the right',
surely often needed for rectangular region demarcation; I believe
such a multiple-move-commands-to-mean-one-single-region functionality
would also be useful, occasionally, in non-rectangular contexts,
so maybe something like: '=<sequence of move commands>=', where the
overall move is not finished until the closing '=', could also be
adopted (non-movement commands should probably be forbidden in
this context?).

:4. What would be a suitable way of handling rectangular regions that
:   do not have enough text (eg:
:
:line1: col1 ... ...  col5
:line2: col1 ... col4
:line3: col1 ... ...  col5
:
:   where the desire is to operate on col4 and col5 of lines 1-3.)
:   Should the operation be flagged with an error and aborted, or
:   allowed, with the missing column filled in with spaces, or even
:   the missing column just ignored?

I believe the most useful default would be blank-filling, possibly
with a :set variable to allow for other behaviors.

:5. vi's syntax is fairly orthogonal, but the special cases are a
:   little confusing at times. Would it be worthwhile to clean it up
:   or would that just be even more confusing?

I believe some cleanup might be useful, but what exactly do you have
in mind since '~' you cover at point 6 - something like 'z+' being
made equivalent to 'z^M'?

:6. vi commands to be changed? Little niggles like where the cursor
:   ends up after an operation. Why `~' can't be prefixed by a count
:   or even modified so that a <move> can be appended. An option to
:   allow all commands to be echoed.

I'd definitely LOVE for ~ to take a <move>!!!  It happens that I
want to case-switch (or, often, force-uppercase or force-lowercase)
a line or a word more often than a single character, I think.  Echoing
might also be nice, as might be visual indication of mode (NOT the
silly way SysV does it, uselessly distinguishing INPUT mode from
CHANGE mode etc, and the absolutely ludicrous "OPEN MODE" to indicate,
NOT ex open-mode operation, but the "variety" of INPUT mode that
'o' and 'O' put you in!!! - just a simple 'INPUT' or 'REPLACE', or,
ideally, cursor-shape change if the terminal supports that), and
optional visual highlighting of "current region" in the '= mode' that
would be created by my suggestion under 3. above.

:7. If we allow macros to take arguments then we need to allow some way
:   to pass these arguments. Counts may be prepended as per normal, as
:   may <move>s be appended, but what would be a clean syntax for textual
:   arguments? All the obvious delimiters are already taken (eg. //, ()).
:   Also, presumably the `:map' command would need to take an extra argument
:   to define whether or not the remapped key takes a count, <move> or
:   text argument. What would be a clean way of doing this?

I have no specific suggestion, but I think that special characters
adjacent to the 'map' word (as per the precedent of :map!) might come
useful, and a macro which wants textual input (like, say, the builtin
'/' key) should prompt at end of screen (possibly with a settable
prompt-string...).
Also, it would OF COURSE be INSANELY GREAT if macros could be expressed
using A PROGRAMMING LANGUAGE (ideally Tcl, but LISP, Basic or ANYTHING
else WOULD do in a pinch...) rather than just 'keysequences'....!!!!

:8. In the tag file associated with a `:ta <tag>' command, the format is

I'll pass on this one, since I hardly use :ta anyway...

:9. Finally, although I am not the world's greatest mouse fan, I allow

Ditto...
--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/407.314 (home only).

In article <1991Sep2.152330.726@csug.rdg.ac.uk> shrchin@rosemary.cs.reading.ac.uk (Jonathan H. N. Chin) writes:
 > I am in the process of designing (if that is the right word to use)
 > a `text' editor. It will effectively be an extended vi clone. I plan
 > to implement most of the features of vi with the exception of  > (I don't know nothing 'bout lisp) and also those of ex, once I can
 > resolve the ambiguities in the documentation I have.
 > Some additions I want to make:

 > - multiple undo/redo
 > - rectangular region manipulation
 > - macros that take arguments
 > - 8 bit clean (ie. can handle binary files if desired, also foreign
 >   character sets, IBM PC graphics, etc)
 > - operations distinct from their key bindings (ie. can remap a key to
 >   perform an operation that includes, as part of it, the initial
 >   operation that the key defined)
 > - unlimited line/file lengths

These are very nice suggestions. However, GNU Emacs already implements
them for its vi mode.

 > Some questions:

 > 1. Does anyone use the `U' command?

Yes.

 > 5. vi's syntax is fairly orthogonal, but the special cases are a
 >    little confusing at times. Would it be worthwhile to clean it up
 >    or would that just be even more confusing?
 > [...]
 > 6. vi commands to be changed? Little niggles like where the cursor
 >    ends up after an operation.
 > [...]
 > [other complaints about differences between "cw" and "dw", etc.]

Regular "vi" users are very used to the little quirks of the "vi"
command set. Yes, "a...<ESC>" or "$" may leave the cursor in an odd
place, but people have gotten used to it. The same goes for the
keybindings.

If your goal is to write a better "vi", you should leave this alone.
If your goal is to write a new editor with "vi" like bindings, you
can, of course, do what you want, but I suspect that most people will i
not use your editor: new users will stick with Emacs (for convenience)
or "real vi" (because it's there and it's standard).

						Thomas.

You might add:

	1) support for multiple commands on a single ex command line
	   (it's a pain to have to keep typing : or change to ex mode)
	   Perhaps some only exit next command in line if current
	   command 'succeeds' (however that may be defined).

	2) support for ed-like scripts (if it doesn't already have
	   that capability)
Ciao,
  Mike

--

Mike Zraly				``Toxic Avengers: They're GROSS!!!
mzraly@ldbvax.dnet.lotus.com		  But they do get girls.''
or c/o seaotter@athena.mit.edu		  -- from TV commercial

shrchin@rosemary.cs.reading.ac.uk (Jonathan H. N. Chin) wrote in
<1991Sep2.152330.726@csug.rdg.ac.uk>:

| 1. Does anyone use the `U' command?

I do occasionally.

| 2. ...  (Does anyone use the `r' command?)

I do very frequently.  Often when I post something that includes f, F, t, T,
or r as a simpler equivalent to a command string or mapping in a previous
post, someone follows up with, "Oh, but I never use that command."

| 6. ... Why `~' can't be prefixed by a count
|    or even modified so that a <move> can be appended.

~{scope} would be nice.  It currently has a built-in scope of l.  In the vi's
I've used, it CAN take a count, but if the count would send you past the end
of the current line, it goes only as far as $, consistent with an implied l.

| Why does `cw' not behave as one would intuitively expect?

That depends on "one"'s intuition.  It suits my intuition fine.  (Actually,
I shouldn't jump on the handcart of that misuse of the word "intuitive."  The
current effect of cw suits my expectations and assumptions fine.)

| For example, given the text "this is a test string" and the cursor
| positioned at the `a', if one types `cw' the `$' appears over the `a'.
| Surely the `$' should appear over the first `t' of test?

No, it should appear over the space between "a" and "test," because that is
the last character that would be changed if cw covered the same scope as dw.
Yes, it is taken as ce (and cW to cE), probably under an assumption that the
word after the move, if it is to be left unchanged, requires the separator
preceding it to be unchanged as well.

| And how about `c/s^M' and `cfs'? Shouldn't they be the same? :) :)
| After all, `/s' puts you onto the `s', not the character before it.

Yes, they should.  d/s^M acts the same way and does dts rather than dfs.
With backward scopes it's pretty standard to exclude the character under the
cursor at the start from c or d operations, and / seems to be treated the
same way: the deleted or changed range includes the first character and
excludes the last.  (Line-based scopes are inclusive, though, no matter which
direction you move in; is that another inconsistency we've grown to love?)

| But seriously, say I `:map z f' and then `:map f F' why does the `z' mapping
| disappear? Why doesn't it remember the operation the f originally was mapped
| to? (This is one of the short-comings I want to fix with my editor).

Doesn't that depend on whether :set remap is in effect?

David W. Tamkin  Box 7002  Des Plaines, Illinois  60018-7002  +1 708 518 6769
dattier@vpnet.chi.il.us  CIS: 73720,1570  MCI Mail: 426-1818  +1 312 693 0591

"Parker Lewis Can't Lose" mailing list:
 flamingo-request@esd.sgi.com (reflector)   flamingo-request@mcs.com (digest)

In <1991Sep4.144408.24398@athena.mit.edu> seaotter@athena.mit.edu (Mike) writes:

>You might add:

What do you mean "add"?

>	1) support for multiple commands on a single ex command line
>	   (it's a pain to have to keep typing : or change to ex mode)

The separator is the | character.

>	2) support for ed-like scripts (if it doesn't already have
>	   that capability)

The usual shell syntax:

ex - files <<EOF
..
..
..
EOF

works for me.
(The - flag tells ex not to print all that garbage to the screen).

Or do you want to add the functionality of the :source command?

--
Hans Mulder	hansm@cs.kun.nl

In <1991Sep3.235648.18317@austin.eds.com> mayoff@austin.eds.com (Rob Mayoff) writes:

>In article <1991Sep2.152330.726@csug.rdg.ac.uk> shrchin@rosemary.cs.reading.ac.uk (Jonathan H. N. Chin) writes:

>>3. What would be a clean way of incorporating rectangular region
>>   handling into the command syntax? `d<move>' is the usual way
>>   of deleting a region, so maybe we need to prepend a <rect> flag
>>   somehow (ie. `d<rect><move>', maybe with `#' or `=' as <rect>;
>>   `|' would be nice but `d|' defaults to deleting back to the start
>>   of the line)?

>I'd suggest revamping vi's targetting mechanism.

Please don't.

>Instead of typing d<target>, let the user type d<as many motion keys as the
>user wants>* (since the * is unused in vi).  That would make deleting funny
>regions much easier.

It would make deleting normal regions 1 keystroke longer.  I delete
normal regions much more often than funny regions.  Thus I can live
with the cumbersome sequence mm<many motion keys>d`m if I have to
delete a funny region.

>I'd do a lot less character counting if I could do that.

Character counting?  Why don't you count words
Or use the {(%)};,fFtT commands?  Or the . command?

>Note that I consider myself a vi expert and a vi bigot; nevertheless, I
>believe that vi could be improved and made much
>friendlier/easier-for-beginners.

Vi is decidedly unfriendly to beginners, but most proposals in this
newsgroup to make it more beginner-friendly would also make it more
expert-hostile.

>>6. vi commands to be changed? Little niggles like where the cursor
>>   ends up after an operation. Why `~' can't be prefixed by a count
>>   or even modified so that a <move> can be appended. An option to
>>   allow all commands to be echoed.

>You should make this a targetted command just like d or y or c, I
>think.

But than you'd have to type 2 characters if you want to ~ just 1 char,
which is the most common case.  Adding a count is harmless.  In fact,
the version of vi I'm now using (SVR3.1), does accept <count>~ .
It would be nice, though, to have a targetted version as well.  But it
would have to be a different command, like x is not d and s is not c.

>>But seriously, say I `:map z f' and then `:map f F' why does the `z' mapping
>>disappear? Why doesn't it remember the operation the f originally was mapped
>>to? (This is one of the short-comings I want to fix with my editor).

>You probably have the remap option set.  Try :se noremap and see what happens.

You didn't try it, did you?

It's a bug, and it's independent of :setting remap.
Remap matters when you use the mapping, not when you define it.

--
Hans Mulder	hansm@cs.kun.nl

In article <1991Sep4.144408.24398@athena.mit.edu> seaotter@athena.mit.edu (Mike) writes:
> 	1) support for multiple commands on a single ex command line

	:cmd|cmd|cmd ...

> 	2) support for ed-like scripts (if it doesn't already have
> 	   that capability)

	:source file
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX  77487-5012;  +1 713 274 5180
"Have you hugged your wolf today?"

I am looking for one... Any suggestions?
--
-Dave datta@vacs.uwp.edu.

Computers are a figment of my imagination. No-one can prove otherwise.

In article <1991Sep4.144408.24398@athena.mit.edu> seaotter@athena.mit.edu (Mike) writes:
>	1) support for multiple commands on a single ex command line
>	   (it's a pain to have to keep typing : or change to ex mode)

You don't; ex uses the '|' character as its command separator.  This may not
work with commands that take a filename as an argument; I'm not certain.

>	2) support for ed-like scripts (if it doesn't already have
>	   that capability)

That's what the :so (source) command is for.  The file given as an argument
contains a list of ex commands.

rob

/ otter:comp.editors / mayoff@austin.eds.com (Rob Mayoff) / 12:56 am  Sep  4, 1991 /
In article <1991Sep2.152330.726@csug.rdg.ac.uk> shrchin@rosemary.cs.reading.ac.uk (Jonathan H. N. Chin) writes:
>1. Does anyone use the `U' command?

Yes.

>2. Assuming the meaning of `u' is going to be changed, how do I
>   incorporate the redo operation, seeing as `r' is already taken
>   (hence Q1 above)? (Does anyone use the `r' command?)

`r' means `replace the character under the cursor with the next
character typed' and I use it constantly.  I'd be willing to sacrifice
U to mean `redo' if I was given multiple undo, because that'd basically
remove my need for U.

>3. What would be a clean way of incorporating rectangular region
>   handling into the command syntax? `d<move>' is the usual way
>   of deleting a region, so maybe we need to prepend a <rect> flag
>   somehow (ie. `d<rect><move>', maybe with `#' or `=' as <rect>;
>   `|' would be nice but `d|' defaults to deleting back to the start
>   of the line)?

I'd suggest revamping vi's targetting mechanism.  Instead of typing
d<target>, let the user type d<as many motion keys as the user wants>*
(since the * is unused in vi).  That would make deleting funny regions
much easier.  I'd do a lot less character counting if I could do that.
Then, for rectangular regions, you could use some other end-of-motion
key, like # (also unused).

Note that I consider myself a vi expert and a vi bigot; nevertheless, I
believe that vi could be improved and made much
friendlier/easier-for-beginners.

>4. What would be a suitable way of handling rectangular regions that
>   do not have enough text (eg:
>
>line1: col1 ... ...  col5
>line2: col1 ... col4
>line3: col1 ... ...  col5
>
>   where the desire is to operate on col4 and col5 of lines 1-3.)
>   Should the operation be flagged with an error and aborted, or
>   allowed, with the missing column filled in with spaces, or even
>   the missing column just ignored?

Offer an option of padding with spaces, or just ignoring the missing
columns.

>5. vi's syntax is fairly orthogonal, but the special cases are a
>   little confusing at times. Would it be worthwhile to clean it up
>   or would that just be even more confusing?

What special cases do you means?  Aside from the `cw' and `ce' which is
mentioned later in your article.

>6. vi commands to be changed? Little niggles like where the cursor
>   ends up after an operation. Why `~' can't be prefixed by a count
>   or even modified so that a <move> can be appended. An option to
>   allow all commands to be echoed.

You should make this a targetted command just like d or y or c, I
think.

>9. Finally, although I am not the world's greatest mouse fan, I allow
>   that they can make certain operations simpler. How could mouse use
>   be allowed without subsuming the functions that the operating system
>   provides (eg. windowing system, cut&paste, scrolling)? (Think of the
>   wonder of it - a vi that automatically resized itself when you changed
>   the size of your window! Or moving through your text using the
>   scroll-bar. (Bye-bye textedit!)) What interface should the editor
>   provide for mouse use? Obviously a plain DOS PC with no windows might
>   not have a mouse at all and neither would a tvi912.

I'd say offering a scrollbar would be a good idea.  Also, let the user
select text with the mouse, and then press one of the targetting
commands (like d or y or c) and have the command implicitly use the
highlighted text.  Allow clicking in the window to reposition the
cursor.  If a user `y's or `d's text, stuff it into the X window system
PRIMARY selection as if it had been `copied' or `cut'.  Let your editor
have its own window under X, and let it open multiple editing windows,
so that only one instance of the program needs to be running.  Have an
interface in your program so that if a copy of it is already running
and another copy is invoked, it simply tells that first copy to open a
new window editing the new file.  GNU Emacs and `iedit' (an editor that
uses the InterViews toolkit) have this functionality.

>Why does `cw' not behave as one would intuitively expect?

Probably because the author of vi (Bill Joy, I believe) felt that
having `cw' change to the end of the current word instead of to the
beginning of the next one would be more intuitive and friendly.  I
agree with you, especially since `ce' already gives that
functionality.

>But seriously, say I `:map z f' and then `:map f F' why does the `z' mapping
>disappear? Why doesn't it remember the operation the f originally was mapped
>to? (This is one of the short-comings I want to fix with my editor).

You probably have the remap option set.  Try :se noremap and see what
happens.  The question you must answer when considering this sort of
thing is how close you want your editor command set to be to a full
programming language.  Should keystrokes be like function calls, so
that if you make a macro, it's like a function that makes a series of
function calls, and if those functions have been redefined, use the new
definitions?  Do you want to offer a full programming language for
writing macros - conditionals, loops, etc?

rob
----------

mayoff@austin.eds.com (Rob Mayoff) writes:

> I'd suggest revamping vi's targetting mechanism.  Instead of typing
> d<target>, let the user type d<as many motion keys as the user wants>*
> (since the * is unused in vi).  That would make deleting funny regions
> much easier.  I'd do a lot less character counting if I could do that.
> Then, for rectangular regions, you could use some other end-of-motion
> key, like # (also unused).

That would indeed be very usefull. An option could tell vi whether to
use the old mechanism or that new one.

> You should make ~ a targetted command just like d or y or c, I
> think.

I agree.

> Also, let the user
> select text with the mouse, and then press one of the targetting
> commands (like d or y or c) and have the command implicitly use the
> highlighted text.

Or the other way round...

> Allow clicking in the window to reposition the cursor.

This is one of the reason why I use (a modified) VIP mode under emacs;
this lets me have the best of both world. But I would be willing to get
back to an enhanced version of vi if there was an opportunity to do so
(as a matter of fact, I do not really fancy vile).

> If a user `y's or `d's text, stuff it into the X window system
> PRIMARY selection as if it had been `copied' or `cut'.

Seems the right thing to do.

> Let your editor
> have its own window under X, and let it open multiple editing windows,
> so that only one instance of the program needs to be running.  Have an
> interface in your program so that if a copy of it is already running
> and another copy is invoked, it simply tells that first copy to open a
> new window editing the new file.  GNU Emacs and `iedit' (an editor that
> uses the InterViews toolkit) have this functionality.

Let also your editor be able to share its window between different files,
so that you are not always in a mess with too many X windows.

Furthermore, let an option turn history on for `:' ex commands and `/'
search strings. Enable vi(-ksh?)-like editing of the command line. Allow
the possibility that the command line on its own be in a separate window.

In addition, add an option that allows you to echo commands as you type
them (sometime you are lost and just press <ESC>).

> Should keystrokes be like function calls, so
> that if you make a macro, it's like a function that makes a series of
> function calls, and if those functions have been redefined, use the new
> definitions?  Do you want to offer a full programming language for
> writing macros - conditionals, loops, etc?

Perhaps a usefull thing when one consider how emacs people have defined
different modes outside of their editor to edit file types (C, Pascal,
Eiffel, Prolog, LaTeX, compressed files, ...).

Jean-Jacques Moreau.


PS: Sorry for the previous response. D was too late to get rid of it.

From the keyboard of jjm@otter.hpl.hp.com (Jean-Jacques Moreau):
:Perhaps a usefull thing when one consider how emacs people have defined
:different modes outside of their editor to edit file types (C, Pascal,
:Eiffel, Prolog, LaTeX, compressed files, ...).

No reason to put this IN your editor.  You can have a front
end that figure it out and loaded up EXINIT appropriately.

--tom

I suggest not changing anything fundamental.  Just add stuff.

Make v and V targeted operators that lowercase and uppercase.  "vv" would
lowercase a line, "Vw" would uppercase a word, and so on.  If you need a
case-toggle operator, you could use '^V'.  All these keys are not bound.
Make '~' accept a count, and otherwise leave it alone.

I like the box approach from Sage Professional Editor: you use some magic
command to draw the box (they use the mouse with the right button held
down) and once you have the box you hit 'd' for delete, 'y' for yank, or
whatever.  For a keyboard command to draw the box, you might use '^X'.

Also please make the default buffer not get clobbered when you switch files.
--
Steve "I don't speak for Microsoft" Hastings    ===^=== :::::
uunet!microsoft!steveha  steveha@microsoft.uucp    ` \\==|

In article <2000006@otter.hpl.hp.com> jjm@otter.hpl.hp.com (Jean-Jacques Moreau) writes:
> mayoff@austin.eds.com (Rob Mayoff) writes:
> > I'd suggest revamping vi's targetting mechanism.  Instead of typing
> > d<target>, let the user type d<as many motion keys as the user wants>*
> > (since the * is unused in vi).  That would make deleting funny regions
> > much easier.  I'd do a lot less character counting if I could do that.
> > Then, for rectangular regions, you could use some other end-of-motion
> > key, like # (also unused).

> That would indeed be very usefull. An option could tell vi whether to
> use the old mechanism or that new one.

AEDIT does this. You type "d <move> <move> <move> d" to delete, "b ... b"
to mark a block, and so on.

It's reasonably nice, but should be a settable option rather than the default.

I'd also like an incremental search...
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX  77487-5012;  +1 713 274 5180
"Have you hugged your wolf today?"

I posted the ">>" lines in this article originally.  Delete these lines
if you're quoting this article.

">" means article <4040@wn1.sci.kun.nl> hansm@cs.kun.nl (Hans Mulder)
">>" means <1991Sep3.235648.18317@austin.eds.com> mayoff@austin.eds.com
      (Rob Mayoff)
">>>" means article <1991Sep2.152330.726@csug.rdg.ac.uk>
      shrchin@rosemary.cs.reading.ac.uk (Jonathan H. N. Chin)

>>I'd suggest revamping vi's targetting mechanism.

>Please don't.

>>Instead of typing d<target>, let the user type d<as many motion keys as the
>>user wants>* (since the * is unused in vi).  That would make deleting funny
>>regions much easier.

>It would make deleting normal regions 1 keystroke longer.  I delete
>normal regions much more often than funny regions.  Thus I can live
>with the cumbersome sequence mm<many motion keys>d`m if I have to
>delete a funny region.

>>I'd do a lot less character counting if I could do that.

>Character counting?  Why don't you count words
>Or use the {(%)};,fFtT commands?  Or the . command?

I do.  I also use / and ? and G and ' and ` but I'd still rather have
the targetting mechanism be a little friendlier.  I'm not saying throw
away the old one; make it an option.  If the goal is to write the
editor that anyone (novice or expert) can use to realize his/her
fullest potential, then there can't be one set way of doing things.  It
has to be configurable.  My ideal targetting mechanism would be to
press the action key and the move the cursor to the destination.  The
original location (where I pressed the action key) would be set to
reverse-video.  Then, pressing some auxiliary key would cause the
action to ``act''.

>>Note that I consider myself a vi expert and a vi bigot; nevertheless, I
>>believe that vi could be improved and made much
>>friendlier/easier-for-beginners.

>Vi is decidedly unfriendly to beginners, but most proposals in this
>newsgroup to make it more beginner-friendly would also make it more
>expert-hostile.

You're right; so stick to vi.  If someone's writing a new vi-like
editor, I'd like to see one that beginners can use.  There are a lot
more vi-novices than vi-experts, and the number of vi novices grows
faster than the number of vi experts.  I daily see people using vi who
get to the end of the file by holding down the down-arrow and waiting.
And waiting.  And waiting.  I'd like to see an editor that will help
people like that.  One with on-line help, and perhaps even a status
line showing things like filename and current mode (*gasp*).  I don't
know if I would use this editor, but if there's going to be another
editor, let's have one that novices can use.  I'm a vi addict, but I
tell new users to use GNU Emacs usually, simply because I only have to
tell them two things about it:

	Type "emacs filename" to edit.

and

	Type "Control-H" (the help key) as often as necessary.

When I used to try to get novices to use vi, I'd have to sit there and
explain repeatedly how to do things, and eventually I'd always end up
saying something like "You might want to go over to the Co-Op and buy a
copy of _Using_the_vi_editor_" (or some other vi book).  No one ever
has to buy a GNU Emacs book, because of the extensive online help
(including a tutorial).  I know such things exist for vi, but (1)
they're not nearly as easy to use, because vi doesn't have a built-in
key-binding to load a help file, and (2) there aren't any such things
installed on the systems at the University of Texas at Austin (where
I'm a student and where I see all these novices).

>>>   Why `~' can't be prefixed by a count
>>>   or even modified so that a <move> can be appended.

>>You should make this a targetted command just like d or y or c, I
>>think.

>But than you'd have to type 2 characters if you want to ~ just 1 char,
>which is the most common case.  Adding a count is harmless.  In fact,
>the version of vi I'm now using (SVR3.1), does accept <count>~ .
>It would be nice, though, to have a targetted version as well.  But it
>would have to be a different command, like x is not d and s is not c.

You're right, two characters.  When I used to argue with a couple of my
friends about vi v. GNU Emacs (they're both GNU Emacs bigots) I'd
always talk about counting keystrokes, and they'd argue that typing
control-P is one keypress, whereas I'd say it's two, and we never got
any further.  But anyway, I don't really count keystrokes anymore.  The
difference between one keypress and two is infinitesimal, IMHO.  I'd
much rather type ~e to change the current word to upper-case than have
to think, "oh, infinitesimal is 1-2-3-4-5-6-7-8-9-10-11-12-13
characters," and type 13~, or press ~ 13 times.  I'd suggest having ~~
change the current character to upper-case - changing a whole line to
upper-case isn't something I'd do very often.  Don't you think that
having to type ~~ for one character is a fair trade for typing ~e
instead of ~~~~~~~~~~~~~ ?  If you don't, that's okay.  This is another
spot where an option setting would be good.  You can't please all the
people all the time.

>>>But seriously, say I `:map z f' and then `:map f F' why does the `z' mapping
>>>disappear? Why doesn't it remember the operation the f originally was mapped
>>>to? (This is one of the short-comings I want to fix with my editor).

>>You probably have the remap option set.  Try :se noremap and see what happens.

>You didn't try it, did you?
>It's a bug, and it's independent of :setting remap.
>Remap matters when you use the mapping, not when you define it.

You're right; I didn't try it.  I thought what he meant was that after
these two maps, `z' was acting like `F' instead of like `f'.  I have
now tried it, and it is indeed an undocumented feature. :-)

My point: there are plently of editors for experts (vi is one and GNU
Emacs counts as infinitely more - that's plenty).  Let's have one
that's really good for novices, and will still be good for them when
they're experts.

As for why I'm not saying GNU Emacs is that editor (to forestall
followups by GNU Emacs fans claiming that it is):  first, GNU Emacs
takes too long to load, even on my SPARC 2, and second (and this will
be hard for many GNU Emacs bigots to comprehend) - I *like* modes.  I
like pressing one key to switch into command mode far more than having
to constantly press ESC or hold down control to do things other than
simple text entry.

Actually, now that I think about it, here's another targetting
mechanism that I like even better than the one I suggested above or the
current one.  Have some "begin-selection" key-binding.  When it's
pressed, you're in movement mode.  As you move the cursor, the text
selected (that is, the text between the cursor and the original
location) goes reverse-video.  When you've selected the text you want
to affect, you press the appropriate key (like `d' for delete or `c'
for change) and the selected text is affected.  A different key could
be used for selecting rectangular regions.  If no text is selected when
a key like `d' or `c' is pressed, then the key acts the way it does in
vanilla vi.  That way, novices can have a nice, visual, interactive way
to affect blocks of text, and old hands can do it the way that's burned
into their fingers.  That also solves the problem with ~ (which should
of course take an optional count).  Does this sound more agreeable?
Of course, the reverse-video bit should be optional, in case of slow
serial lines or whatnot.

rob

I had tried to mail this directly, but it bounced.

--

This is a suggestion for rectangular operations:

	Suppose I have some columns I want to delete.  Then
	I might try the command 20#30dd.  That is, delete the
	the next 20 columns from my cursor and 30 lines down.

	Now, since dd puts the deleted text into a buffer, that
	rectangle is free to be placed somewhere else with the
	p or P command.  This implements the rectangular move.

	Clearly, a copy can be done with 20#30yy.

Let me know what you think.  In any case, I will probably try to
implement this myself into the JSTEVIE sources I have.

--
James Hu, 1804 Denholm, Manhattan, KS 66502
jxh@math.ksu.edu will work just dandy!
--
Life, the most valuable natural resource.

In article <1991Sep5.200225.7006@austin.eds.com> mayoff@austin.eds.com (Rob Mayoff) writes:
>Have some "begin-selection" key-binding.  When it's
>pressed, you're in movement mode.  As you move the cursor, the text
>selected (that is, the text between the cursor and the original
>location) goes reverse-video.  When you've selecte the text you want
>to affect, you press the appropriate key (like `d' for delete or `c'
>for change) and the selected text is affected.  A different key could
>be used for selecting rectangular regions.  If no text is selected when
>a key like `d' or `c' is pressed, then the key acts the way it does in
>vanilla vi.  That way, novices can have a nice, visual, interactive way
>to affect blocks of text, and old hands can do it the way that's burned
>into their fingers.

This is EXACTLY the direction that elvis has been taking.  In the beta-test
version of elvis, lowercase 'v' starts marking characters in reverse video;
uppercase 'V' starts marking whole lines.  When you hit one of the operator
keys (c d y < > !), the operator is immediately applied to the marked text.

It doesn't offer any way to mark rectangles, yet, but when/if it does, it'll
probably use ^V to start marking the selection.

In addition, the '\' key is a new operator key.  It calls up a menu which
allows the user to choose a command to be run.  (The menu has nearly all
of the operators on it, plus "cancel", "undo", "paste before", "paste after",
and "save & exit".)

For novices, I'd suggest a .exrc file such as this...

	" Make <F1> start marking characters,
	"      <F2> start marking whole lines,
	"      <F3> invoke a menu that acts on the marked text
	" These keys should run visual commands, even if the user presses
	" them while in input mode.
	map #1 visual v
	map #2 visual V
	map #3 visual \

	" Start in input mode, and give the user a lot of feedback.
	" If the user exits input mode, then tell him/her how to get
	" back into it.
	set inputmode novice ruler

The beta-test version of elvis is available via anonymous FTP from
m2xenix.psg.com, in the directory "pub/elvis/beta".  The current version
is 1.5g.  (A week ago, I posted an invitation to grab 1.5f, so I guess
the beta-testing really is working!)  *** Grab the "READ.ME" file first! ***
-------------------------------------------------------------------------------
Steve Kirkendall     kirkenda@cs.pdx.edu      Grad student at Portland State U.

In article <1991Sep2.152330.726@csug.rdg.ac.uk> shrchin@rosemary.cs.reading.ac.uk (Jonathan H. N. Chin) writes:
>3. What would be a clean way of incorporating rectangular region
>   handling into the command syntax? `d<move>' is the usual way
>   of deleting a region, so maybe we need to prepend a <rect> flag
>   somehow (ie. `d<rect><move>', maybe with `#' or `=' as <rect>;
>   `|' would be nice but `d|' defaults to deleting back to the start
>   of the line)?

One possible way of dealing with rectangular region specification might be to
mark two corners in the usual way (e.g. ma and mb) and make

    :`a,`by

do the "right" thing (cf. 'a vs. `a in the current vi, and :'a,'by).

		Mark.
--
Mark Valentine, Spider Systems <mark@spider.co.uk>            /\oo/\
"Tigers will do ANYTHING for a tuna fish sandwich."
"We're kind of stupid that way."

In article <1991Sep5.200225.7006@austin.eds.com> mayoff@austin.eds.com (Rob Mayoff) writes:
>I daily see people using vi who
>get to the end of the file by holding down the down-arrow and waiting.
>And waiting.  And waiting.  I'd like to see an editor that will help
>people like that.  One with on-line help, and perhaps even a status
>line showing things like filename and current mode (*gasp*).  I don't
>know if I would use this editor, but if there's going to be another
>editor, let's have one that novices can use.  I'm a vi addict, but I
>tell new users to use GNU Emacs usually, simply because I only have to
>tell them two things about it:
>
>	Type "emacs filename" to edit.
>
>and
>
>	Type "Control-H" (the help key) as often as necessary.

I suggest
   :set novice  (being the default)

With novice set, it would print hints on the last line.  If you hit
d, it would print "Now hit a cursor movement key to delete to".  If you
hit m, it would print "Now give the name of the mark you want set to the
current position."  There could also be another key that would, at any
stage, show you a list of keys you could hit and what they would do.
It would categorize them into ones that a novice might actually care about,
and ones that they won't use until they're experts, instead of listing off
*every* *possible* command you could type, like GNU emacs.  (Personally,
I find GNU emacs help difficult to use, since it tells me so much more than
I wanted to know.)  In order to get the user started, the novice mode would
load up and print "<whatever key> lists commands" on the line at the bottom.

>As for why I'm not saying GNU Emacs is that editor (to forestall
>followups by GNU Emacs fans claiming that it is):  first, GNU Emacs
>takes too long to load, even on my SPARC 2, and second (and this will
>be hard for many GNU Emacs bigots to comprehend) - I *like* modes.  I
>like pressing one key to switch into command mode far more than having
>to constantly press ESC or hold down control to do things other than
>simple text entry.

Well, I'm not a GNU emacs fan, but I had it pounded into my head by one
at my job over the summer that you can avoid the first problem with GNU
emacs.  Apparently, there's a little program that comes with the newer
distributions of GNU emacs called 'emacsclient' that loads a file into
a new buffer in an already existing emacs.  The idea is for you to be able
to run emacs once (say when you start x windows) and then run emacsclient
from then on.  Personally, I hate the way that makes everything global,
instead of neatly categorized in separate windows.  That's one thing I
like about vi - it doesn't go opening a separate window that I have to
keep track of in my brain and leaving the current window empty and idle.

lshaw has new mail waiting; last read on Fri, 06 Sep 91 10:08:20 EDT
I like modes to.  The absolute most annoying thing about emacs is trying to
move forward (or back) a few words.  To do that, you must hit M-b M-b M-b,
and since ESC is usually the Meta character, *I* always end up hitting
something like ESC-b ESC ESC-b, to which emacs responds "You have typed ESC
ESC, invoking disabled command eval-expression:"... and basically fills the
screen with novice mode garbage (which takes forever at 2400 baud).  Of
course, I've also hit 'b' after hitting ESC ESC, which makes it beep at
me.  Then I have to figure out how to get out of novice mode, restore the
buffers like I had them if novice mode has covered up something else,
figure out where I was and try again.  In vi, I just hit bbb and it's
done.  (Oops, this turned into an emacs peeve.  Oh well.)

>Actually, now that I think about it, here's another targetting
>mechanism that I like even better than the one I suggested above or the
>current one.  Have some "begin-selection" key-binding.  When it's
>pressed, you're in movement mode.  As you move the cursor, the text
>selected (that is, the text between the cursor and the original
>location) goes reverse-video.  When you've selected the text you want
>to affect, you press the appropriate key (like `d' for delete or `c'
>for change) and the selected text is affected.

I *like* it...

Later,
   Logan
--
____________________________________________________________________________
"Surely every man walks about like a phantom; surely they make an uproar for
 nothing; he amasses riches, and does not know who will gather them.  And
 now Lord, for what do I wait?  My hope is in Thee."  - Psalms 39:6-7

In article <992@cadlab.sublink.ORG> martelli@cadlab.sublink.ORG (Alex Martelli) writes:
>shrchin@rosemary.cs.reading.ac.uk (Jonathan H. N. Chin) writes about a
>vi-enhanced-clone, and I respond here since I would like others' input.
>:1. Does anyone use the `U' command?
>I do, but only occasionally, and if I could multiple-undo I could
>probably often use that instead of the undo-all function of `U'.

If you had multiple undo, then you could use that instead of U. If you
think about it, then U is just undoing all the operations on that line
anyway. With multiple undoes U becomes redundant.

>:2. Assuming the meaning of `u' is going to be changed, how do I
>:   incorporate the redo operation, seeing as `r' is already taken
>:   (hence Q1 above)? (Does anyone use the `r' command?)
>`r' is VERY heavily used.  I guess redo, a rarely used command, would
>be nice to map to <negative number>-undo, if only there WAS a way to
>prefix *negative* number (a nice idea in general, I believe...).

Same here.

>:6. vi commands to be changed? Little niggles like where the cursor
>:   ends up after an operation. Why `~' can't be prefixed by a count
>:   or even modified so that a <move> can be appended. An option to
>:   allow all commands to be echoed.
>I'd definitely LOVE for ~ to take a <move>!!!  It happens that I
>want to case-switch (or, often, force-uppercase or force-lowercase)
>a line or a word more often than a single character, I think.  Echoing
>might also be nice, as might be visual indication of mode (NOT the
>silly way SysV does it, uselessly distinguishing INPUT mode from
>CHANGE mode etc, and the absolutely ludicrous "OPEN MODE" to indicate,
>NOT ex open-mode operation, but the "variety" of INPUT mode that
>'o' and 'O' put you in!!! - just a simple 'INPUT' or 'REPLACE', or,
>ideally, cursor-shape change if the terminal supports that), and
>optional visual highlighting of "current region" in the '= mode' that
>would be created by my suggestion under 3. above.

No. keep it like it is.

>:7. If we allow macros to take arguments then we need to allow some way
>:   to pass these arguments. Counts may be prepended as per normal, as
>:   may <move>s be appended, but what would be a clean syntax for textual
>:   arguments? All the obvious delimiters are already taken (eg. //, ()).
>:   Also, presumably the `:map' command would need to take an extra argument
>:   to define whether or not the remapped key takes a count, <move> or
>:   text argument. What would be a clean way of doing this?

This would be useful.

>Also, it would OF COURSE be INSANELY GREAT if macros could be expressed
>using A PROGRAMMING LANGUAGE (ideally Tcl, but LISP, Basic or ANYTHING
>else WOULD do in a pinch...) rather than just 'keysequences'....!!!!

No. No. No. No. You want lisp, you know where to find it.

>:8. In the tag file associated with a `:ta <tag>' command, the format is
>I'll pass on this one, since I hardly use :ta anyway...

I'm always using :ta.

Dylan.
--
dylan@ibmpcug.co.uk || ...!uunet!ukc!ibmpcug!dylan
  Never trust a programmer with a screwdriver.

I have a suggestion: a real macro language, with key bindings and all. But
not a lisp based one... a real small one that can be parsed in about 10K
of C source, something forth-like that compiled into tokens would be ideal.
the forth parser reduces to "read next word on input, look it up, and execute
a command or add it to the currently compiled word".

(speaking as one who has implemented a vi-like forth screens editor)

: range ( default-char special-char --- from to 1 | 0 )
  getch 2dup = if ( def spec key )
    drop drop 1 ( drop key and default )
  else
    swap drop swap drop ( drop default and special )
    dup is-movement-command
  fi ( key 0 | key 1 )
  if ( if the next key is a movement command )
    dot swap ( save position ) perform ( old 0 | old 1 )
    if
      dot over ( old new old ) goto 1
    else drop 0 fi
  else drop 0 fi ;

: tilde
  ' ' '~' range if
    do
      i getch dup isalpha if
        '@' xor i replace
      else drop fi
    od
  fi ;

tilde '~' bind-to-key
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX  77487-5012;  +1 713 274 5180
"Have you hugged your wolf today?"

Unless this is simply for instructional purposes (it doesn't seem to be), this
whole reimplementing-vi thread is fucking ludicrous.  Pick an editor with a
powerful extension language and extend it.  If you happen to choose one that's
shareware, you can also muck about with the sources and low level constructs
all you like.  Don't implement unless you're going to see serious improvement.

Concerning vi usage for scripts, peter@ficc.ferranti.com writes:
> :source file
How 'bout ":source /dev/tty"?

Regards, [Ag]

peter@ficc.ferranti.com writes:
> I have a suggestion: a real macro language, with key bindings and all. But
> not a lisp based one... a real small one that can be parsed in about 10K of C
> source, something forth-like that compiled into tokens would be ideal.

I really don't understand this bias against Lisp.  If nothing else, it's a hell
of lot more functional and readable than Forth.  Don't get me wrong, though, I
like Forth and think Peter's suggestion has some merit.  Implementers, consider
writing a Forth interface to GNU Emacs.

Regards, [Ag]

In article <Sep.8.12.03.10.1991.5119@romulus.rutgers.edu> gaynor@romulus.rutgers.edu (Silver) writes:
> Unless this is simply for instructional purposes (it doesn't seem to be), this
> whole reimplementing-vi thread is fucking ludicrous.

Why? Some people *like* vi.

> Pick an editor with a
> powerful extension language and extend it.

What do you do if the editor with the powerful extension language has basic
designed-in semantics that drive you crazy? Or if you're dealing with a system
that's close enough to the edge you can't run one powerful enough? The Micro
Emacsen don't qualify.

> Don't implement unless you're going to see serious improvement.

> Concerning vi usage for scripts, peter@ficc.ferranti.com writes:
> > :source file
> How 'bout ":source /dev/tty"?

Try "Q". Or explain more about what you need to source /dev/tty for?
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX  77487-5012;  +1 713 274 5180
"Have you hugged your wolf today?"

In article <Sep.8.12.18.47.1991.5212@romulus.rutgers.edu> gaynor@romulus.rutgers.edu (Silver) writes:
> peter@ficc.ferranti.com writes:
> > I have a suggestion: a real macro language, with key bindings and all. But
> > not a lisp based one... a real small one that can be parsed in about 10K of C
> > source, something forth-like that compiled into tokens would be ideal.

> I really don't understand this bias against Lisp.

It's too big.

> If nothing else, it's a hell
> of lot more functional and readable than Forth.

Readable, yes. Functional, no.

> Don't get me wrong, though, I like Forth and think Peter's suggestion
> has some merit.  Implementers, consider writing a Forth interface to
> GNU Emacs.

Sort of misses the point of fitting the extension language into 10K or so,
doesn't it?
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX  77487-5012;  +1 713 274 5180
"Have you hugged your wolf today?"

Here are a few other suggestions which I don't believe have been mentioned.

1.  The user should be able to set more options.  For example, the
definition of the end of a word and the end of a WORD.  (I would prefer
to see them reversed).  Preferably, the definition could be any regular
expression.

2.  The ability to have more than one pattern (as with / and ?)
and the ability to search more than one pattern away.

As a sub-point, provide an option so that <action> (delete, etc) to a pattern
does not change pattern.  Sometimes it is convenient to search to a
pattern and then delete to another pattern.  Then search for the
orginal pattern again.

3.  The ability to edit ex commands and patterns.  One convenient
feature would be the ability to append to a pattern rather having
to type the entire pattern over again.  (That is, the pattern is
not restrictive enough.

4.  The hard-coded *roff stuff should be removed.  I should be able
to define a paragraph anyway I want, which might include any line that
begins with white space, etc.

David