	(E means enhancement, L,M,H are low, medium, high priority)
----------------------

E	everybody and their sibling wants "map", "map!", and "abb".
	there is now fledgling support for this, courtesy Otto Lind.
	Still no map! or abb, and nested maps are broken in a couple
	of ways, but it's a start...  oh yes, one other thing -- :map
	currently only supports single key mappings (i.e.  you can map one
	vile key-sequnce to a string, but there is no string to string
	mapping).

	    [ a user writes: vi's map/map!  has problems in treating
	    numbers of ^V in different platforms.  And mail/newsreaders
	    don't like those control characters.  I suggest you consider
	    the bindkey style in tcsh that uses \e as ESC, \r as return
	    etc.  vile is not just a vi emulator anyway. ]

E	add "set autowrite", ":n file" (what does that do?), "set noredraw"

E	now that paragraphs, sections, and sentences are all selectable
	with regexps, they (and the tabstop value) are prime candidates for
	moving into a "mode-values" set of values.  A buffer would inherit
	either the global normal-mode values, or the global c-mode values.

E	:k, to set a mark, won't work as ":ka" or ":kb".  Must use ":k a"

E	patterns as addresses do not work, e.g. ":/str1/,/str2/d".  They're
	hard to parse the way things are set up right now.  We could accumulate
	the whole commandline, and then parse it, the way real vi does, but we'd
	lose the "prompt and display last response" behavior.

E	should add an option to support file locking, rather than the current
	ifdef stuff.  (this is only useful if we match the GNU locking
	protocol.) And it's not clear that in an NFS'ed environment that
	it's all that easy to get that style of locking right anyway.

E	the scrsearch functions could become region based -- as in "search for
	the next occurrence of the region", which would usually be a word.  And
	the ^A/ version could become "a/ (search for the contents of buffer a),
	if you know what I mean.

E	g should become a region command.  Then it could take ranges, as
	it should, and could also become an operator command.

E	adjust window size of popups based on length of buffer.  currently
	popups get half the window they're splitting, no matter what

E	collapse command execution code to as few places as possible.
	Its currently spread through execute(), operator(),
	docmd(), and usekreg().

E	mlreply line should ideally be a one line buffer, so inline editing
	can be done on it.

E	I haven't even come close to testing vile for
	memory-full conditions.  Some malloc() packages give 95%
	warnings -- perhaps something like that should be done for
	safety.

E	marks should perhaps be linked onto lines.  this would make a lot
        of things a lot easier, since a mark would travel with the
        line, instead of having to be moved when the line is
        reallocated etc.  the U line could be treated as a special
        mark.  The "copied" flag needed by undo could be a special
        sort of mark as well.  Implementation of the "tag stack"
	would be aided by this as well.

L	vile really ought to use unix-crypt if it is available.

E	can't search for a NUL in a buffer.

E	":e" and ":e!" should share the same prompt data, which should be
	editable / history.  They both should default (like vi!) to the
	current buffer.

E	the "ww" command (e.g., 'writeall()') emits multiple messages via
	'mlforce()'; these go by too quickly to follow.
	[ the alternative currently is to require a press-return, which some
	  folks don't like. ]

E	for consistency, 'execute-macro-nn' should be 'execute-macro nn';
	doing this would allow modification to eliminate a fixed number of
	macro-buffers.

E	should ifdef the 'autobuffer' code for users who do not need vi-style
	buffering.

--------------

    Is it possible to get vile to prompt you if you try to exit without
    viewing all the files that were given on the command line?

--------------

    The ed 'transfer' and 'move' commands don't work.
    (to copy and move text around.  e.g., :'a,'bt$.)

--------------------------------
486 PC under Dell Unix (svr4) - make:    unixpc
HP9000/700 under HPUX 8.07    - changes: do not include <Xos.h> in x11.c when
                                         hpux is defined
                                incs:    add -I/usr/include/X11R4
                                libs:    add -L/usr/lib/X11R4
                                make:    hpux
Tektronix XD88/10 under UTekV - changes: removed LIBS definition from svr3 rule
                                         in makefile to make xvile
                                cflags:  add -DSYSV -X28
                                make:    svr3
----------------------------------------------------------------------

Though I use it, I'm still not quite satisfied with the qident stuff.  It
needs to be more flexible.  That is, I'd like to make it user defined.
For example
	find-tag $qidentifier
should be expressable as a character class like
	find-tag &anyof "a-zA-Z_0-9:"
in a macro.  Or even more generally, as a regular expression:
	find-tag &scan "[a-zA-Z_][a-zA-Z_0-9:]\\*"
A leading ^ would root the search at the current cursor position.
Absence of a leading ^ would start at the current cursor position but would
scan ahead until it found a match.  That way I can redefine ^] to pick
up the next word even if the cursor is before the start of the word (thus
better mimicking vi's behavior).

[ This can almost be done with the $match variable, e.g.
	7 store-macro
		search-forward "[a-zA-Z_][a-zA-Z_0-9:]*"
		find-tag $match
	~endm

	bind-key execute-macro-7 ^A-g
 - pgf ]
----------------------------------------------------------------------


In message <9212231610.AA27630@cuba.Cayman.COM> you write:
>
> > The rest (regexp.c) fix problems with
> > \S \w \W \d \D \p \P never matching the first character on a line.
>
>Actually, I could have sworn I put in the check against BOL to prevent some
>infinite loop or other oddness -- but I'll put certainly apply your change
>until proven otherwise...

The only remaining pieces of oddness I've seen are
1) doing ?\w when already on a \w character -- it says Only one occurrence
of pattern.

1a) doing ?\W when already on a \W character -- it says Only one occurrence
of pattern.

2) doing /\s stops at the end of a line and won't go any further (because
the cursor rests on the last character of the line which is before the eol).

[ these are both tricky to fix... i tried, and started introducing problems
elsewhere. -pgf]

----------------------------------------------------------------------
Also, I encountered the following problem: I am editing foo.tex and
call latex using ^X!latex foo.tex. There is an error, so latex waits for
input -> vile sits waiting and nothing helps. I think this should
be interruptable. I will agree with you that the ^X! command was not
intended for this, but still...

But ok, the real problem is that after I kill latex and
vile comes back to life I can no longer filter parts of text using
!fmt. The text just gets deleted.

----------------------------------------------------------------------

I just grabbed a copy of xvi.  I noted some interesting tidbits while
reading the "differences between vi and xvi" document.  Some of these would
be nice in vile.


     As well as the normal named (conjugate) buffers, and the  default
     one  named @, several extra buffers named :, /, ?  and ! contain
     the last command lines entered for each of the command types.  So
     for  instance,  @: will re-execute the last colon command, or you
     can insert it into your buffer, edit it and  then re-execute  it
     (e.g. with dd@@).


     +    In insert and replace modes, ^A has the same meaning  as  ^@
          in  vi,  except  that it works at any time, not just for the
          first character.  Also, typing ^Bx, where x is the name of a
          conjugate  buffer,  inserts the contents of that buffer into
          the input stream at that point.  The buffer named  <  always
          contains the last thing inserted, so that ^B< is the same as
          ^A.


------------------------
I wish ^X-!  could execute shell commands async'ly, i.e.  I should not have
to wait/do nothing while waiting for the ouput of compiling.  I should be
able to edit stuff in other buffers or even ^X-^X to edit src codes
while compilation is still going on.

------------
similar to above -- sub-commands run from ^X-! or ":[erw] !cmd" should be
"interactive" to the extent that user's input should be sent to the cmd
at least on a line-by-line basis (i.e. we can't send raw keystrokes -- we
have to do canonical processing.  of course, we should really use pty's, and
reconnect input and capture output.)  some commands like latex prompt for
more input when partway done.

========(VMS-VILE)=============================================================
Unfinished items on vax/vms (dickey@software.org):

	+ the response time seems a bit slow (compared with other applications
	  running on the same machine).  possible problem areas include:

		+ observed that (at least on vms) I am getting highlighting
		  attributes being reset on each line, rather than only when
		  they change.

		+ probably am making too many calls to canonpath and
		  lengthen_path (affects performance on vms).

	+ if the current directory has changed, offer to restore it on exit. 
	  (Note that if the _device_ portion has changed, the original
	  directory should be restored anyway!).

	+ filename-completion works too slowly on vms; may be doing stat calls
	  or something else.  Also, it does not seem to start properly with

	  	":e e?".

	+ add key bindings and other support to make the vt100 keypad work for
	  me (e.g., like EDT).

	+ see if I can decode ".dia" files, if so connect it to finderr.c

	+ catch exception/signals, and restore terminal settings.

	+ make dec-shell names work in file-completion.  These are quasi-unix
	  filenames, which most of the VAX-C runtime routines accept.  If _all_
	  runtime code could use dec-shell names, I wouldn't have done any
	  native vms pathnames (sigh).  As it is, all dec-shell names are
	  automatically converted to vms-pathnames (i.e., by 'getname()').

	+ make write-pipes work (actually, flesh out to use 'npopen' coding
	  scheme, like the MSDOS stuff).

	+ I had a case in which I wanted to read the contents of one file into
	  another; they had the same buffer name; the target buffer got the
	  filename for the source, e.g.,

	  	:e []foo		- read and determined version # ok
		:r [-.temp]foo		- current filename reset to [-.temp]foo
------------------------------------------------------------


it would be nice if vile would fold text...

	This feature appeared in uEmacs version 3.10.23 and you can
use archie/xarchie to file fue.tar.Z (fue - folding-micro-emacs).

[ someone said they were going to fold this in, so to speak.  i'm not
real comfortable with the idea, since the uemacs code causes the LINE
struct to grow _enormously_ ]


-----------

	When I execute a keyboard macro using ^X-& I cannot repeat this
	using the dot command. Instead, the last command in the macro
	is repeated.
    [ this is because '.' doesn't do @ macros either...]

------------------------------


Can you add the '>' character to the list of comment chars for paragraph
reformatting?  I would live to be able to reformat mail quotes (like shown
above).

[ pgf notes: I did this, as chris suggested, but formatregion should use
  the comments regexp to match a comment delimiter at the beginning of
  line, and should insert the comment delimiter of the _second_ line (so
  that boxed C comments work right)in subsequent reformatted lines,
  including leading but not trailing whitespace.  indentlen should be
  counted _after_ the width of such a comment delimiter.  this would make
  paragraphs that are indented way after the delimiter keep their indent. 
  commented paragraphs should end when exp->mlen for the comment regexp is
  equal to llength(DOT), i.e.  it's the whole line.  (we'll need to take
  the $ off the end of the comment regexp).  ]

--------------------


enhancement:  reimplement error finder using regexps.

------------------------------
Another enhacement.
How about a history file.  say I have been using vile and
quit and come back in later I can use the history file.

--------------------------

In a xterm window the down arrow (which sends ESC-O-B) works for individual
presses.  If you hold down the key then letter Bs get peppered through out
the file.  It appears that the ESC is occasionally being missed so that the
following OB puts a B in the file.

In my case I'm on a workstation running 4.1.3 and xterm using rlogin to
connect to a 690 server (lightly loaded) running 4.1.3 and running vile
on the 690.

I just ran vile locally and didn't see the problem.
-------------------------------


I found a bug (new with 3.59) on our Pyramid SVR4 (but not Pyramid SVR3,
SunOS 4.1.1, AIX 3.2) where
	xvile tmp &
pops up the xvile window briefly, the window dies, the xterm I started
xvile from says
	[1]  + suspended (tty input)  xvile3.59 tmp
and then after a couple seconds the xterm itself vanishes!  However,
	xvile tmp
works fine, except that the process is in the foreground.
 > The bug on the Pyramid SVR4 machine with xvile & suspending itself,
 > committing suicide, and then blowing away the xterm still exists.
 > For the time being I just remember to run xvile on a different
 > machine.

-----------------------------
apply Alistair's min/max regexp patch

-------------------------------------------------------------------------

Is there any way to use termcap to define 
all of the window parameters, but still use ANSI escapes for colors?  Elvis
allows me to do this under Linux on the terminal screen and a couple of
systems allow Elvis to change the foreground and background colors under an
xterm.  If I tell Vile to compile using ANSI instead of termcap it works
but it doesn't seem to recognize any of my termcap variables (which means
it doesn't get the right screen size or exits with incorrect colors).

-----------------------------


With vim 1.27 you can configure its behaviour regarding backspace using
the 'backspace' variable. From the help file:

backspace (bs)	    number    0     0 standard Vi, 1 delete NL, 2 delete all
i.e. if bs is non-zero, you can backup to the previous line, and if it's
a 2, you can backup past the insertion point.

i don't think this is optimal -- i think you should be able to choose
independently whether you backup past the newline or past the insertion point.

in any case, vile won't let you back up past the newline during an insert.
when _not_ in insert, you can rebind ^H to backward-character.

---------------------------

When you do a :b you should have line completion for the name.

---------------------------

We are running vile version 3.61 under NeXT and we have problems with
the redraw. I mean, when I press ^F or ^b (next-page or previous-page)
I get some spurious charactersa in the screen. With a ^L all is back
to the normally. The some is goiing on when I perform a search.

Also we have problems when we accidentally press ^J.  Vile is hanging
in this situation.

---------------------------

I was wondering if it was possible to delete/cut the highlighted region
(from the selection with mouse button one)? 
---------------------------

How can I read the status of a shell command when I execute a
shell-command? Although the shell command has a $STATUS=1 the
status of the status variable is TRUE.

---------------------------
Vi has an autowrite option that will write out a modified buffer
any time a shell command is executed (it also writes out modified
buffers at other times as well).

This would be most useful for the edit, make, execute cycle.
---------------------------

 > 
 > 2) In xvile :set cmode does not work. :set all keeps giving nocmode.
 >    (Linux)
are you sure you're setting the right cmode?  the local vs. global setting
can be a little confusing...

 > 
 > 3) I cannot give xvile a filename at startup. (Linux)
it ignores the argument?

 > 
 > 4) I cannot run xvile in the background. (Linux)
what are the symptoms?

-----------------------

Is it possible to bind keys which give a sequence like ^[[5~, that is other
than ^[O<char.>, longer than 3 chars?
[ not currently  -pgf ]


---------------------

you can't use ! as a regular expression delimiter, as in:
	:s!pat!replace!g
because the parser treats ":s!" as if it's ":q!" or ":w!".

---------------------

pcvile: there's no cursor visible in some of the less-used video modes,
like 40x12 or 40x25.

----------

the ^W and ^R commands don't work with shell-files, i.e.
	^WG!lpr
or 
    	"a^R!cat foo

this seems to be a result of ending up down in kbd_pushback() called
from hst_append().  this causes the clexec flag to be set, and that
breaks a bunch of other stuff.  

-------------------------

width of a region is kept in units of offset, not of columns.
i think this will break rectangular inserts of non-rectangular regions,
where the longest line may not extend to the furthest column, due to
tabs in other lines.


-------------------------

In vile 3.65 on SunOS 4.1.3, when I do execute-keyboard-macro while
defining a keyboard macro, vile seems to go to an infinite loop (but can
be stopped by Ctrl-C).  

------------------------


I found something strange in xvile: if a specify a startup file with @
it dumps core:

xvile @.vilerc

segmentation fault (core dumped)

[unreproducible here.  -pgf ]

------------------------

I compiled Xvile for hpux and had a problem with x11.c, because the X11R4
Xos.h include file does its own definitions for struct timeval when USG
is defined.  Thus I undefined USG before Xos.h was included and re-defined it
afterwards, like

#include        <X11/keysym.h>
#ifdef USG
#define RESTORE_USG
#undef USG
#endif
#include        <X11/Xos.h>
#ifdef RESTORE_USG
#define USG
#endif
#include        <X11/Xatom.h>


-------------------------------------------------------------------------------

Hi, This is to report a 'xvile' v3.65 problem:

- With the defaults (no ~/.vilerc), if I use :e to edit a file, then
  use :e again, but instead of inputing a filename, if I press ^C it
  aborts the action. However if I have ~/.vilerc
	set-terminal name-complete \e
  the above doesn't work (the interrupt function
  doesn't work when completing a filename)...

- Once I got a very strange thing -- with the "set-terminal" command in
  my ~/.vilerc, I was editing several files. Then I tried to use the :e
  command to bring in another file. But then I realized that's not what
  I wanted, so I hit ^C (I'm not sure whether I hit ESC by accident or
  not). Then 'xvile' displayed a "working..." note at the bottom right
  corner -- after 2 or 3 seconds, the X server (X11R5, patch level 24,
  SunOS 4.1.3) crashed!

  However I couldn't reproduce this... I don't know what exactly I
  typed... Just let you know...

------------------------



2) When I use the MKS "fmt" program to format a paragraph in vile, a
   tmp file (aaxxx.tmp) is always dropped out in my current working
   directory.  This was not a problem in the previous version of PCVILE
   (the one I compiled with Turbo C++).

    I.E., when I exit vile43 after using the fmt command, I've got a temp
    file called "aaac1.tmp" (for example) in my current working directory.
    It's annoying.


-----------------------------



I'm using the DOS version and I prefer to use 80x28 or even higher res like
80x50 by setting set sres=80x50 in vile.rc.  The problem is that when a
command is executed with :!<shell-command> the mode switches back to 80x25.
It switches back to 80x25 permanently. I think it's acceptable that it
switches to 80x25 when it's in shell command execution.  However, technically
it should switch back to the preferred mode when it's done.

[ I don't see this on my omnibook... ]

---------------------------

the borland console driver won't display the cursor on blank lines until
after you've refreshed the screen at least once, e.g. with ^L.  must
be something to do with color initialization, or something like that...


---------------------------

doing a ":e foo*.c" reads in all matching files.  it should instead read
in the first, and mark the others as unread, at let them come in later.
in addition, the order in which they come in is odd, at least under autobuffer
mode -- i think they should be available with :n, and they are not.

