OS/2 Shareware BBS: 5 Edit/05-Edit.zip/os2vile.zip/BUGLIST

Text File | 1993-02-03 | 14KB | 340 lines

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

H    The mvrightwind and mvleftwind functions are broken -- visiting lines
    that are too short to be visible when the screen is shifted will
    cause junk on the screen.

E    should add a "show-vars" command

E    everybody and their sibling wants "map", "map!", and "abb".
    the first step to supporting this is making macro/dotcmd replay be
    properly fully nested, and generalized.  I think, for instance that
    if an @a macro invoked a @b macro, or a ^X-& macro, there'd be
    reentrancy problems.

E    add "set autowrite", ":n file" (what does that do?), "set nu", "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    should the "value'd" modes be variables?  vice-versa?  Probably the
    notion of variables should be unified with the values somehow, possibly
    via a new valueset containing just the variables.  they would not
    be inherited by buffers, but would always be global.  the CSUFFIXES
    value would be a good thing to move there, since it doesn't make sense
    as a per-buffer value.  Or else the variables should be checked for
    matches after the rest of the value sets.

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    In vi, the join command is supposed to act either on a region (from
    the command line, as in ":13,15j"), or it should take a simple
    count, from vi mode, as in "3j".  Right now vile _only_ does the
    simple count form of the command.

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 teh contents of buffer a),
    if you know what I mean.

E    need a "file newer than buffer" warning.  Should stat the file, and
    store it's mod time, compare to current when going back to that window,
    after performing some shell command, or just before modifying it.
    e.g., if you're editing a file that is created by a script you're
    testing, then you want to be warned that the file is out of date
    after doing a test run of the script.

E    should implement tagpath, and/or multiple tags files as well.

E    it would be nice if ^X!! reran the last command into [Output]

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 editing
    and history can be done on it.

E    BSD interrupt processing is botched during a read() of the keyboard.
    The read doesn't return -1 as it does under sysV (USG).
    So you can bang on ^C all day and nothing will happen.  It does work
    if you're not in a read(), of course.

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.

E    :e and :n should be able to deal with multiple filenames resulting
    from filename globbing.  vi has this problem too.  At least
    vile lets you choose to choose the first such name.  if should show
    you the first name, so you know whether to accept it or not.

E    vi lets you say: "set ai nows ic".  These must be separate commands
    in vile.

E    When a line is too long to fit on the screen, you have to move
    over it to see the rest, and when you get to the edge of the screen,
    it jumps. I would prefer a smooth(er) scroll.

E    File completion would be nice for commands asking for filenames.
    This saves a lot of typing.

L    "I found a problem when using vile with encrypted files.  During a file
    edit if I set the mode to crypt and save the file, I am prompted
    for a encryption key.  When I try to read in this encrypted file in
    another session using "vile -kcryptkey file".  I am prompted for
    the encrypt key and when I type it in, I get the message
    "Encryption String: IOT trap".  "  [ Anyone wanting to work on this,
    I can send you more info -- pgf ]

E    The vi '_' command isn't supported -- it's similar to stuttering
    when used as an operator controller, and similar to '^' when used
    as a simple motion.


E    Do autoindent after labels and case statements (lines ending in ':')
    Alternately, _back_up_ if you type either of `case ' or `default:'.
    and shift back all the way to the left for `label:'
    In either case) then return the `normal' indent for the next line.

E    in autoindent mode: 0^D and ^^D don't work

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

===================================================

    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?

    It would be nice if the cmode-style autoindenting would do the
    same thing with () and [] as it does with {}.  This would be
    useful for writing function calls with lots of arguments.
[ hard ]

    In cmode, is it possible to get vile to return to the previous
    indentation on the line after a # directive?


===================================================

    There is a bug in the regular expression code.  The expression
    's/./=/g' should change all the characters on the lines to an equal
    sign.  Yet, here is what happens:

    This line should turn into all equals:

    but, :s/./=/g yields:
        =h=s=l=n= =h=u=d=t=r= =n=o=a=l=e=u=l=:

    Every other character is skipped.  (A pointer incrementing problem?)

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

===================================================

    vile running in an xterm terminal has the
annoying habit of moving the status bar line when scrolling up with
^U or ^E.  This leads to the impression of 'flicker' that is very
hard to get used to.  Is there any easy fix for this, or is this a
consequence of the way the termcap entry is set up?

(add "use scroll regions" setting to force there use, termcap notwithstanding)

===================================================

PCVILE

    - globbing (e.g. ":e *.c") does nothing under DOS -- the code in
    expand_wild_args() can probably be used to accomplish this.

    - filter-region -- this would be easier if I had used named pipes
    as the conduit between child and parent, instead of regular pipes,
    'cause then I could just replace the named pipe with a tmp file
    under DOS.

    - some function keys return 8 bit characters on the PC.  This means
    the input path, through tgetc, has to be 8-bit clean, we need to
    allow 256 bindings instead of the current 128, and we can't use
    0x80 as the definition of the SPEC bit.  All this is easy -- it
    just needs to be done.

    - there used to be a "set screen {25|43|50} command -- what happened
    to it?  should 'set-variable $sres "CGA"' do the same thing?  if not,
    what's it for?

===================================================

PCVILE

Firstly - UNISYS 80286, EGA screen, 4DOS command shell & NNANSI.SYS

1) Attempting to shell out to 4dos results in running COMMAND.COM.  Is
   this because COMSPEC is not checked ?

2) Attempting to redirect the output of a 4DOS internal command into a
   buffer works erratically.

    a) :e !dir        - never works
    b) ^X-!dir        - works BUT when followed by;
       ^X-!set        - I get the dir listing again.


3) During testing I noticed another odd result when running the command;

    :!set

   I notice that the output starts on the status line and will overwrite
   it before continuing onto other lines.  However running

    :!dir

   appears to print out just fine.

4) Points 1) & 3) I have previuosly raised with Peter Ruczynski on his
   version.


===================================================

PCVILE

Sigh, well, I removed vile from my DOS box today.  Reason:  earlier
today I had cut over to it as my editor of choice and I noticed that
after using vile for a long period of time and then typing:

    :w        (save file)

I would get an error message from vile saying that it was unable to
access [PRN] (the DOS printer port).  Vile then gave me an opportunity
to Retry or Abort?, but ignored all responses from the keyboard,
including ^C.  I had no choice but to reboot.  Oh well, I figured, just
a fluke.  But then the same problem occurred an hour later.  At that
point I saw no alternative but to remove the program from disk.  I sure
can't debug this problem because I know for a fact that the PC version
of Vile is not using your released base of source code (it can't be
because it handles command line file globbing, which your source does
not support for DOS).


===================================


PCVILE


1) PC-vile wants all of its filenames to be specified with back
   slashes.  Blech.  Everybody's DOS products (except Microsoft) accept
   both backward and forward slashes in filenames.

2) PC-vile quickly exhausts DOS memory when it opens a large file
   or a large tags file.  This can easily be fixed with a compiler
   that supplies a DOS extender (ala Intel's CodeBuilder).  The
   problems I was experiencing with attempts to "write to PRN" may
   also be related to out-of-memory conditions that aren't being
   trapped by DOS or the editor.

3) If your screen starts out in 50-line mode when you enter PC-vile,
   and then exit, PC-vile puts the screen in 25-line mode.  Not
   nice.

4) If you start editing PC-vile with a full block cursor, PC-vile
   switches you back to a small underscore cursor.  Veeeeerrrrrrry
   unfriendly.

5) PC-vile scrolls the screen a page at a time when you browse code
   with the 'j' or 'k' key.  This is totally contrary to the way
   Vi scrolls code and it annoys me tremendously.

6) PC-vile does not internally glob file names (e.g., :r t*.c) does
   not work.

7) The supplied makefile does not work under DOS due to command
   line overflow (but you knew that).

===================================================
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 ]
----------------------------------------------------------------------
What about the possibility of adding vi's (and perl's) \u \U \l \L \E.

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

Xvile works nicely with the middle mouse button to paste text.  It mangles
text a bit when doing the selection, however.  Multiline selections
include all that (visual) whitespace at the end of the line (yes, after
the newline), so when I paste them I get n lines each 80 bytes long!
Plus long lines (that have a > indicator at the right column) get
truncated at 80 columns.
----------------------------------------------------------------------

Xvile has problems with mouse selections if the line has been sideways
scrolled.  It moves to an earlier part of the line.  This is obviously a
problem of convert mouse coordinates to a column position but neglecting
to offset by the horizontally scrolling.
----------------------------------------------------------------------

Enhancement:  xvile would be nicer with scroll bars.