REPORT BUGS TO kirkenda@cs.pdx.edu (STEVE KIRKENDALL) NOTE: Each bug in this file is marked with either "*", "/", or "?". The "*" means the bug is still pending. The "/" means that I believe it has been solved. A "?" means that I've done some work on it, and *hope* it is solved because it seems to work better but I never really understood what was wrong in the first place. A "?" will become a "/" if I don't receive more reports of that bug. More than 80% of this file lists *fixed* bugs. NOTE: Not all of these are truly bugs. This file also serves as my "to do" list, so some items are just unimplemented features that sounded like a good idea at one time or another. * In Windows, elvis.exe can accept filenames with spaces in them, but vi.exe can't. This sounds like a bug in the _spawnvp() system call. Should 32-bit programs even be calling _spawnvp()? This won't be fixed in time for 2.2. If that's a problem for you, then copy elvis.exe to vi.exe. * When you give a command like ":dis s c++", elvis stores exactly that as the value of the display option. This can confuse x11's toolbar buttons. The [Syntax] button will not be drawn pushed it, because it expects "syntax". * For "inputtab=identifier", the normal tag search doesn't look for tags in elvispath, so it doesn't find library functions. Is that a good thing or a bad thing? * The data/elvis.clr script should be able to use ":color!" (with a !) but can't because some of the compiled-in defaults are executed after that script is sourced, so the compiled-in defaults override ":color!". * MAYBE support "or color" for backgrounds. Try to minimize the contrast with the normal background, instead of maximizing it, so the foreground colors still look good. The "or color" backgrounds don't need to support images. * In "man" mode, when markups are displayed the ^J is shown with a black ^ and a highlighted (as "markup") J. * Implement vim's "startofline" option. * The showmatch option currently doesn't use matchchars. Should it? Actually, it does use it to determine whether XML tag pairs should be highlighted by showmatch, but that's all. * See Luigi Mastrangelo's mail for some WinElvis bugs. * If :make encounters a large number of errors, then WinElvis can get stuck in an infinite loop. This didn't happen in 2.1_4. * "WinElvis test*" will, if there is no file with the prefix "test", display an alias on the last line. I tried to reproduce this one. For me, it's working correctly. I've cleaned up the wildcard matching code a lot since 2.2i (which he's using), so maybe that explains it. I hope so. * The tag stack doesn't seem to work right for user-defined protocols. Directories (the "readDIR" alias) fail completely when you hit ^T, and others such as readDICT move the cursor to the wrong place. * Name completion for aliases isn't perfect. If an alias has the same name as a built-in command, then Elvis counts both versions as being different possible completions. * Move source into a src/ subdirectory. This includes just about everything except data/, doc/, README.html, COPYING, INSTALL, HISTORY, and parts of configure and Makefile.in. * The "e2" script would also need to be changed. * In URLs passed on the command line, anchors aren't handled correctly. Try "elvis 'README.html#2.2i'". The same is also true of URLs passed to an ex command that expects a file name, such as ":e README.html#2.2i". There's a difference between URLs and filenames. When elvis knows it is processing a URL it can be very smart about it. But when given a local file name which happens to contain "#" how can elvis know if the "#" is part of the name, or an anchor? And if it is an anchor, how can the generalized file loading code remember that it is supposed to search for that anchor? When following a link from another HTML file, URLs are handled like tags. This won't work for URLs given on the command line, though, because there's no source document for the URL to be relative to, and also because the tags aren't going to be processed in "html" mode. * Elvis' CHAR data type may clash with some standard ones. * Add a help: protocol (readHELP alias) which looks up terms via :help. This way, the README.html file can have links into the manual. Tricky! Too tricky for 2.2 at this late date. * In syntax coloring mode, how about adding a text object for comments? * Write a wrapper around GDB to allow it to run in a separate xterm window. The wrapper will send commands to Elvis which force Elvis' windows to stay in sync with the debugger. See "Annotations" in the GDB info pages. * For some users, the smartargs option is extremely slow and doesn't find the function's arguments anyway. This has to be due to some quirk in the user's configuration, but what? An unsorted "tags" file? This could be in the current directory, or any file or directory named in the "tags" or "elvispath" options. Or maybe it is sorted differently. The "tags" file should always be sorted by the characters' ordinal values, regardless of the locale. Some versions of Exuberant Ctags use locale-specific sorting. See messages from Merijn Brand Would it be worth implementing the search code in elvis itself, instead of invoking ref, just for the sake of removing ref & bash from the scenario? * Need a way to remove folds. This is different from merely unfolding, which remembers the attributes of the fold. * Add a "rulerformat" option to control the appearance of the ruler. Vim has a "rulerformat" option with a very weird syntax. I would prefer to use "simpler syntax" expressions. $1 current line number $2 current column number $3 offset from the beginning of the file $4 offset from the beginning of the line $5 the record/modify flag $6 the decimal code for the character under the cursor $7 the "list" version of the character under the cursor So the default format is equivalent to "$1($5?$5:",")$2". ? simoN reports that he gets intermittant "file's timestamp has changed" messages for no apparent reason. ? Sometimes "x11" doesn't refresh windows in response to an Expose event. * If a visual selection is in effect and you use : to enter an ex command, then non-visual maps don't work while entering the ex command. That's wrong. This turned up as consequence of ":map! ^H ^OX" which should make the backspace key erase text immediately. That mapping also has other problems -- it can't delete the first character in a line, for example. * The :gui commands should be saved by :mkexrc. Also, :gui! should make changes which aren't saved; the standard initialization scripts should use that. * MAYBE add vim's glob(), globpath(), and expand() functions. fnamemodify() too? * Make the default array delimiter be '\n' if the string contains at least one '\n', or whitespace otherwise. This will affect the :for command as well as arrays. This will be handy when glob() is implemented. How does this relate to the idea of using {} to delimit nested arrays? I guess I'd need to do the {} test before the \n test. One complication on the {} idea: The ex parser doesn't store the { itself in the command, or the closing } either. It does store the newline after the { though. Maybe the parser could treat a newline as an opening quote for a string that extends to the end of the expression. Also, \n in strings isn't converted into a newline. Changing the expression parser to support that might break some Windows scripts. The danger is pretty low, though. Adding \n support makes sense. Maybe other character escapes too. * In elvis.syn, the "config.sys" entry reveals a problem: If a language has "ignorecase", and its keywords aren't given in lowercase, then elvis can dump core. I worked around this by changing those keywords to lowercase, but I'm not satisfied with that. Elvis should never dump core. * For the sake of vim compatibility, the X11 PRIMARY selection should be named "* instead of "^. Also, it would be nice if "+ could be used to access the X11 CLIPBOARD selection. * Allow the @ command to accept a count. E.g., 42@x should run the contents of cut buffer x, 42 times. * Find a better way for :map to distinguish predefined maps from those that should be saved by :mkexrc. Currently, it omits any maps for keys that have a label, which isn't quite right. * In Windows, the text-mode elvis doesn't switch screens anymore. This may only be in WindowsNT/2K. There are some differences between consoles in WinNT/2K and Win95/98/ME/XP. * Allow the search commands to accept a count. E.g., 5/foo^M should search forward for the fifth foo. * There are some quirks in incremental searching. For example, the word completion macros don't work with incrementalsearch set. * Add an "UnknownCommand" autocmd event. It should be automatically invoked if an unrecognized ex command name is given. After the autocmd completes, elvis should check again to see if a new alias has been defined with that name, and if so then no error is reported. This will allow elvis to automatically load aliases as they're needed. * Implement vim's "scrolloff" option. It would be handy in the ("Eel) buffer. In vim this is a global option, but I'd like to make it a window option instead. Also implement "sidescrolloff". * Just a thought: If there was a "hidden" text attribute, then it could be used in man pages for text between .de and .., so macro definitions wouldn't be displayed. Also, and could be hidden. * If no normal background has been specified, or the background is set to "transparent", then changing the "background" option should cause a BgChanged event. It should also re-evaluate all colors to possibly choose a different foreground. * For smartargs, would it be possible to make the ',' character be overtyped only by another ','? And maybe make any typed ',' delete text up to the next ',' in the doomed text. That would be nice, because then as users type arguments, one typed argument will replace one smartargs hint. Modify syntax descriptions to store multiple function characters. For example, the line "function (,)" would tell elvis that '(' starts a function's args, ',' separates args, and ')' ends args. If only two characters are given, assume the arg delimiter is space. If only one is given, then don't treat any characters specially. * Modelines set a buffer's options okay, but can't set the window's options as part of a :sp command because that window hasn't been created yet. * It would be nice if ex/xbuf.ex could leave the other toolbar buttons unchanged. Maybe allow multiple toolbars? I also want to support menu bars, and maybe a right-click menu. Maybe elvis should support generic widgets which can have an associated ex command (optionally with a form), and/or a list of other widgets to be displayed as menu items or toolbar buttons. The only difference between a menubar and toolbar would be their appearance -- the menu bar doesn't show icons. Widgets wouldn't necessarily be displayed anywhere. You could define a large number of widgets that people *might* want to use, and then choose which ones serve as menu bars or tool bars, and which ones appear as menu items or toolbar buttons in those. New options would list the top-level menues, toolbars, and a right-click menu; some of those options could be buffer-dependent. Each widget should have the following attributes: * Label - the string used to identify it in elvis' config files. * Short - a text description of the item used in menus or button labels. This defaults to the same as the label, with "_" changed to " ". * Long - a text description, displayed on the status line and in the dialog (if there is a dialog). The default is the same as Short. * Sensitive - an expression which is TRUE if the widget can be clicked. The default is TRUE. * Chosen - an expression which is TRUE if the widget should be shown as being chosen (i.e., a pushed-in button, or a checked menu item). The default is FALSE. * Command - an ex command line to execute when clicked. * Dialog - A description of the dialog window to be created when the widget is clicked. If the widget also has a Command then the Command is only executed when the Dialog's [Okay] or [Apply] button is clicked. * Menu - a list of widget labels, specifying the contents of a window to pop-up when the widget is clicked. If there is also a Dialog and/or Command for this widget, then Dialog/Command is used for short clicks, and the Menu is used for longer clicks (or right-clicks). * Icon - a small image to use in toolbar buttons. There is no default; the widget's short name is displayed instead. * Implement the "redraw" option? * If a URL contains percent signs or hash marks, it is hard to enter because elvis wants to replace those characters with the name of the current and alternate files, respectively. At least, this is true with user-defined protocols. * Make the ex/info.ex script use the "dir" page. See ex/info2.ex * Traditionally, "-" has been a synonym for the "-s" flag, for running scripts. This is still part of POSIX, though is marked as being "obsolete" there. To make "-" be treated as a file name, you must give "--" before it, as in "elvis -- -". Can I make elvis smarter about that? Maybe I could make "-" act like "-s" when stdin is a file, and read text from stdin otherwise? Users could still use an explicit "-- -" to force the read-text behavior, or "-s" to force the script behavior. Sadly, there is no 100% portable way to detect whether stdin is a file or not. The test would have to be done in an OS-dependent way. The isatty() function tests for character devices, not files. The fstat() function uses funky names in Windows, and might not always work on non-files. * Implement support for vim's CursorHold event. (This occurs when the user doesn't cause any input events for a configurable amount of time, under control of the "updatetime" option, expressed in milliseconds.) * htmltagatcursor() is still too slow in some contexts. * For the sake of speed, dmmuadjust should probably not do any adjusting until the buffer is displayed. That way, if there are *MANY* changes, we only need to adjust the display list once. Idea: Only regenerate when needed -- which mostly means while drawing a window. For each window, keep track of the last offset that has been generated. If a buffer is modified before that point, then reduce the window's offset to the changed point, and discard any saved formatting information after that. When regenerating a window, start at the last saved point before-or-at the top of the screen, and work forward until the window is filled, saving points as they're generated. This should be at least as fast as the current method -- probably much faster. More reliable too. The save points could either be the start of every line (which would make the points be dependent on the width of the window) or some specific tags which mostly force a new line to start (which would *NOT* depend on a window's attributes). The "every line" method sounds simpler, but I'll need to remember to clobber all of the saved info if the display mode changes, or the width changes. Important comment: /* Start on the line BEFORE the one where changes begin. * This is because if we insert a small word at the front of * a line, it might fit at the end of the preceding line. */ * The "syntax sh" display mode doesn't highlight instman.sh very well. I think this is because dmsyntax.c:setup() allows strings to start at the end of a line. If a string punctuation occurs at the end of a line, it is much more likely to be the *end* of a string. * Make "x11" support a real bold+italic font. * In X11, maybe use XTranslateCoordinates() to choose position of dialog window. * Add a urlencode() function. And maybe urldecode() too. * Need a way to check options of other buffers. For example, it would be nice if the toolbar in ex/xbuf.ex could test each buffer's "modified" option. Maybe use the -> operator. The lhs would be a string identifying the buffer, and the rhs would be the label of an option to fetch. It would work by *TEMPORARILY* changing the bufoption value. This is mostly needed only in expressions, not the lhs of a :let command, because there you can use (bufname) to get a similar effect. local b let b = newbuffer() (=b) let bufdisplay = "syntax sh" calc b->bufdisplay * It might be nice if the :man alias could search for the man source text, instead of recreating it from the nroff output. Ideally, this would use a "manpath" global option (or just use $MANPATH, I guess) and a buffer- specific "mansection" option to store a list of sections and extensions. The mansection option is intended to address the problem of looking up write() in a C program -- it tends to find either the write(1) program, or the Python equivalent of the system call. * Add an event when marks are set/reset. This way users could... :au MarkSet * '[,']region marked '(aufile) :au MarkUnset * '[,']unregion marked ... to highlight the marked line. Or maybe a generic "Normal" event which is triggered whenever a vi command is executed? See vi.c:1089, and add a TWEAK flag to indicate which commands trigger events. :auevent MarkSet :au Normal m* '[,'] doau Markset I guess this would also require the :doau command to be extended to accept an address range. That sounds useful all by itself! * It would be nice if there was a way to stuff data into a cut buffer. One example: Use it to copy the current file name into the display's selection. Vim uses @x for this... and even uses the :let command! :let "^ = current("file") * Add stubs files for X extensions, OpenGL, etc. * Maybe reimplement :g to work in two passes, like the real ex/vi. * Add a buffer option for controlling the default face. In addition to "normal" and "idle", some candidates would be "readonly" and "web". * The '' command (go back to previous location) doesn't seem to work as well as it used to, especially after :s/// commands. * Apparently "elvis -Gx11" doesn't always exit when X does -- it can get stuck in a loop where it uses all available CPU. Xlib normally kills the application when the connection to the server goes down unexpectedly. Elvis will sometimes disable that behavior during initialization -- perhaps it doesn't enable it afterward? * Can the new "prefix" keyword thing be extended to denote comments? And the %rX...X regular expressions in ruby? Maybe recognize the start of a comment/regex as a prefix token, and associate a terminator string and font with it. Maybe it could even handle preprocessor directives! * Windows problems: * In Options->Font, the "Font style" is ignored -- can we remove it? ? WinElvis died one time while resizing, when it tried to refresh the screen. I haven't been able to reproduce this. ? Is there a bug in Windows reading the initialization scripts? In particular maps that use the ^M character? I can't reproduce this. It works correctly for me. * Potential for some minor problems with parsing regular expressions, when magicchar is set to something weird. Specifically, some parts of regbuild() and gettoken() assume that '[', '^', and '$' are always in magicchar. If they aren't, then odd (though non-fatal) things will happen. * Add support for vim's \= in replacement text. It treats the rest of the replacement text as an expression, evaluates it, and uses the result as literal replacement text. E.g., :$s/^/\=current("line")/ inserts a line number at the start of every line. Maybe use $1 - $9 for \1 - \9, but how to handle & ? * Some of the special characters in "man" should be graphic, but aren't. This is somewhat improved in 2.2h, but still needs work. * Add a "regexp" (or "magicsyntax" ?) option which has no built-in purpose but can be used with ":autocmd OptChanged regexp ..." to automatically adjust the syntax. auevent RegexpChanged au OptChanged regexp eval doau RegexpChanged (regexp) au RegexpChanged perl set magicchar=^$.[*+?(){\| magicname magicperl au RegexpChanged vi set magicchar=^$.[* nomagicname nomagicperl Actually, it might make more sense to allow users to create their own options. "regexp" could be an instance of that. * In regular expressions, maybe allow all of the \letter combinations have configurable meanings. One way to do this would be via 52 magic options, with the value of the option being substituted for any \ sequence used in a regular expression. This could interfere with the use of \Q, \V, and \E. I should leave those hardcoded, with \E selecting the enhanced mode that is sensitive the the magic options. If I'm going to do all this, then the regular expression options should probably all be collected into a "regexp" group. There will be a lot of them! * In regular expressions, allow [[:startword:]] and [[:inword:]] to be used for accessing the syntax-coloring concept of "word". * Maybe add a way to prevent :w from saving some types of regions. This would be handy for a visual diff -- you could show both the old and new versions of lines mixed in the same buffer, and then save only the new text. This could be done via a macro, but I'm worried that it'd be too easy to accidentally bypass the macro, causing the mixture of both versions to be written to the file. Also, it might be nice if the "no save" lines could be hidden by setting an option. I wonder... would it be adequate if I simply made elvis sensitive to the special face name "nosave"? * When editing the source-code for man pages, there is a bug in the handling of { and } paragraph commands, which affects the "ap" and "ip" text objects: If the cursor is on the '.' of a .PP or .SH command, then the paragraph seems to include the PRECEDING text instead of the CURRENT AND FOLLOWING text. * Compatibility issue: The `m command should move the cursor back to the same column, not the same character. I.e., it shouldn't care whether any text has been inserted or deleted on that line before the mark. To test, go onto a long line and type 40|mm20|10x`m -- this should leave the cursor in column 40, but elvis moves to column 30. * :10,20s/foo/bar/3 should change lines 20 through 22 -- i.e., 3 lines starting at the last line in the range. Elvis ignores the count when given a range, which is wrong. * :g/^/j should join pairs of lines (it does in the real vi and in vim), but instead it joins all lines together into a single line. * The S command looses the last indentation character when autoindent is set. Also, c_ (which is what S does) works the first time, but . doesn't, if the new text was empty. If the new text was not empty, then . looses indent. * When pasting rectangles at the ends of lines, elvis doesn't try to pad the lines so the rectangle keeps its shape. Vim does. * tags don't work except in HTTP: URLs? * If multiple tags occur in a line, *not* as a menu, then elvis should load the image when ^] is pressed on one of them. Instead, it always seems to load the first image in the line. (Though I'm not 100% sure I understand what's really happening.) * Change the meanings of some commands when a visual selection is pending: * s Like c (rect repeats the change for each line) * C Change whole lines (except rect changes from left edge) * S Change whole lines * D Delete whole lines (except rect deletes from left edge) * X Delete whole lines [:map select X :d^M -- but cut buffers?] * Y Yank whole lines [:map select Y :y^M -- but cut buffers?] * I Insert at left edge (for rect, do it to each line) * A Append at right edge (for rect, do it to each line) * Some useful 'g' commands that elvis doesn't support yet: * gv reselect previously highlighted text * ge go backward to end of previous word. * gE go backward to end of previous WORD * Some useful 'z' commands that elvis doesn't support yet: * zh sidescroll leftward. If cursor forced off right edge, move it. * zl sidescroll rightward. If cursor forced off left edge, move it. * zs sidescroll to move cursor's column to left edge * ze sidescroll to move cursor's column to right edge * The :fold command seems to confuse the :g command, perhaps because :fold changes the meaning of "line". The :unfold command is okay, though. In particular, this means you can't do this... :g/^{/,/^}/fold (current("tag")) ... but this works... :g/^{/,/^}/unfold (current("tag")) :%fold! ? The spell option should probably look for tags in more places. Currently it doesn't seem to check any tags file except the current directory. Actually, it was apparently checking only the directories listed in the "tags" option. Perhaps it should also check "elvispath"? If there is no "tags" file in the current directory, then it doesn't look in other tags either. I remember this was a design decision, to speed things up in non-source directories. I might want to make this an option, or make it sensitive to knownsyntax(), or something. NEWSFLASH: I think this issue is moot, since the new taglibrary option was created. * Extend the "ref" program to limit itself to looking at tags that are callable from a specific source file, by checking the extensions against the "extensions" or "foreign" set, just like tagkind/taglibrary. * Make elvis give a higher priority to tags that are callable by the current source file, using the same filename sensitivity. This would be a little tricky, since the list of extensions is currently stored in a static variable in descr.c. * Make "tagkind" option store a separate tag/keyword dictionary for each buffer. This will handle static tags, and also allow the keywords to be reloaded when the "tags" file changes. (As currently implemented, tagkind adds tags to the language's shared keyword dictionary.) One big challenge: Currently, the list of filename extensions which are callable by the language is stored in a static variable in descr.c This works when the search only takes place as a language is loaded, but if we need to reload later, then we'll need to store that list somewhere -- probably attached to the language description in descr.c * When lpcolumns!=columns, printing will often use the wrong font attributes when printing text in a markup display mode. Apparently the array of line attributes is tripping it up. NEWSFLASH: It can cause core dumps too. Try setting lpcolumns=300, for example. This is especially true when using antialiased fonts in "x11". This should go away with the new markup code (when written). Until then, just be sure to ":let lpcolumns=columns" before printing. * Maybe implement a multi-level progress bar. Search/replace commands would use it, as would network I/O. Aliases could also use it via a ":progress name=percent" command. The progress is reset (goes away) whenever elvis is idle, or when the progress hits 100%. While reset, the first named progress grabs it, and holds it until reset again. This should probably wait until window-at-a-time idle is supported. * hlsearch doesn't mark all matches within a markup display mode. Its behavior is very consistent, in that it fails to highlight the same instances each time. This would be hard to fix -- probably not worth the effort at this time. The ideal solution would involve modifying regexec() to search across line boundaries. The problem is caused by the fact that markup display modes have a different definition of "end of line" than the regexp matcher, so any text between a newline character and the end of the "markup" line is unchecked. * Giving too many "Hit to continue" prompts. * "spellsuffix" doesn't always work. It seems to skip looking for base words defined via :words -- it only checks the "spelldict" dictionary. Example: "GUI" is added via :words, and spellsuffix contains "'s", but "GUI's" is still flagged as an error. I believe there are two things happening here. First, it doesn't look for the root word in the tags dictionary; this allows lowercase "digraphs" to be flagged as an error even though "digraph" is accepted because it is a tag. This is not a bug. The second thing is that it looks up the root word in a case- insensitive way (converting it to lowercase) so it doesn't find the uppercase "GUI" when trying to check "GUI's". This is a bug... how to fix? ? From Stephane Billiart: There is a bug in the "configure" script -- it doesn't know that the internet files are required even if the network protocols are not used, with the "x11" interface. Here's a patch that fixes it for Solaris... 529,531c529 < why " to ensure that 'const' is ignored. Also, if X11 is to be supported then" < why " we also need -lsocket -lnsl. A -R flag may also be added so the X11" < why " shared libraries can be found at run time." --- > why " to ensure that 'const' is ignored." 535a534,535 > why "For Solaris2, X11 requires -lsocket -lnsl. A -R flag may also" > why " be added so the X11 shared libraries can be found at run time." 538a539,542 > elif [ X"$inet" != X ] > then > why "For Solaris2, any network access needs -lsocket -lnsl" > TLIBS="$TLIBS -lsocket -lnsl" Okay, here's my question: How could the network files be present but not used? The "configure" script always uses HTTP and FTP if the network files are present, so that should always cause those files to be included under Solaris, right? Or does Solaris sometimes have the libraries but not the header files? ------------------------------------------------------------------------------ FIXED BETWEEN 2.2j and the official 2.2.0 release / Use x11's colors as the defaults for WinElvis too. Actually there are no defaults for XElvis either. I should probably add a data/elvis.clr script which sets up default colors for both graphical elvis and text-mode elvis. The ~/.elvisrc file can be a good starting point. / The data/stubs/unixstub.c file seems to be very incomplete. / "make install" should be forgiving about the /etc/elvis directory. If a user runs "configure --prefix=$HOME" and installs elvis as themselves (not "root"), then "make install" shouldn't fail because it can't write to the /etc directory. / The readDIR alias loads the new buffer into the old window. This causes problems with the stack, or with :sp commands. This is similar to the problem I had earlier with the rcssince alias, which was run via an autocmd event. I solved that by adding a rule that autocmd events can never switch buffers. The same solution would probably work pretty well for protocol aliases. / In Windows, the standard COMMAND.COM shell does not expand wildcards, but Cygwin's bash.exe does. Elvis shouldn't expand wildcards if they've already been expanded. Obviously elvis will need some way to tell the difference -- perhaps by checking for a SHELL environment variable. See the following. / Wildcard expansion is closely tied to handling of parentheses. It would be nice if, during wildcard expansion of command-line arguments from the shell, we could skip that stage. Maybe create a new option? Set it during processing of the command-line args, and then turn it off before processing the configuration scripts. This would also prevent parentheses from being eaten in file names such as "file (2).txt". A more general option might be nice -- one that lets you control the aspects of filename handling in detail. Its value could be a subset of "tilde,dollar,paren,wildcard,special,space". "special" allows interpretation of %, #, and (if supported) , as well as the :x modifiers that can follow those symbols. "space" indicates that commands which accept multiple names should divide the name at any unquoted space; without that, you could only separate the names with characters. Call the option "filenamerules". So, for Unix/Linux, the command line args would be interpreted using filenamerules="". For Windows arguments (without $SHELL) filenamerules="tilde,dollar,wildcard". After that, the default is always filenamerules="tilde,dollar,paren,wildcard,special,space" -- the full set -- but you can change it in ~/.elvisrc. Windows users might want to take out "space". Name completion should insert a tab after a complete name instead of a space, if the "space" flag isn't given. / If the user tries to get help for an alias defined with a '!' then look in the elvistip.html file. Otherwise just say it is an alias. / When told to read a directory, elvis should pretend it was told to read using the "dir:" protocol. Users can define a readDIR alias to allow directory browsing. / In X11, :mkexrc can save italicfont="". It shouldn't. / Elvis' BOOLEAN and data type may clash with a standard one. Change its name, and the names of the True and False values. / Elvis' ctype macros clash with the standard ones. This is a problem in some GUIs because they use headers which #include . Change the names of elvis' ctype macros. / In "x11", adds ^Sff63. Is this a general problem? starts marking in addition to sending ^Sff51. (It is normal for to start marking text.) Probably shouldn't send anything. Even weirder: It starts marking in the main buffer even if you type in an ex command line. / Use notation for maps in elvis.ini, and :mkexrc. Not only is this more readable, but it also avoids fileeol() confusion when reading maps that end with ^M. / I think the region bug may not be completely fixed. The "since.ex" script eventually causes problems, sometimes, when it tries to add a region for the current line when the line is changed. I think this is related to "undo", which can move marks. It could leave regions unsorted. To reproduce it: Make the second paragraph if this file be a region. Delete the its last line. Hit . Hit to insert a line above the last line. Wham! / With "matchchar=ax showmatch", an empty tag pair does not get highlighted because the ix object would have zero length. A general solution for this might not be possible. If matchchar=ab then typing {} won't cause the { to be highlighted either, for the same reason. Is it worth implementing a special case just for ax? / Draw the screen-filling '~' lines in the "nontext" face. / In doc/elvistip.html, the old "spelltags" option is mentioned. Update description there to say what elvis really uses now ("spell"). / The :autocmd system's DisplayEnter and DisplayLeave events are quirky. If you use DisplayEnter to adjust the "list" option for various display modes, then sometimes the screen is refreshed before the option is changed, so the screen is wrong until you hit a key. The audisplay() function detects this type of change. As currently implemented, the DisplayEnter/DisplayLeave events are oriented toward adjusting maps in a display-dependent way, so audisplay() is called before processing keystrokes, and detects global changes to the display mode, not changes to a specific window. This is useful, but doesn't work well for adjusting options that affect the way text is displayed. / Rename the current DisplayEnter and DisplayLeave to DispMapEnter and DispMapLeave. Also rename the audisplay() function that is used to trigger it. / Create new DisplayEnter and DisplayLeave events that are triggered when a window's display mode changes. The DisplayEnter event should also be triggered when the window is first created. Basically this should be triggered when win.display is changed. / Extend the listchars option to support a "markup" flag which allows "list" to display markups. The presense of "markup" indicates that markups should be listed; its absence indicates that markups should be hidden by "list". / Making :s always succeed in a :g turns out to have been a bad idea. Some scripts and aliases, such as :makehtml, depend on errors from :s when there is no match. I should implement vim's "e" flag. / Need a good way to display sets. Write a :wrapset alias to do that. / Modify name subscripts to support sets. L.name and L["name"] should return "True" if L contains name without a value; else it should return the value. For missing names it should return "", which is a false value. When assigning to L.name, always store name:value, never just name. If the option contains the name without a value, then the name should be deleted from the value. / Add set operators that act on comma-delimited lists of names. L & R Return the names that appear in both sets. If values are preset, then keep the value from R. L | R For each name in b, add it to a if it isn't already in a. If values are present, then keep the value from R. When adding values, try to insert them to keep the a sorted. L ^ R Remove items from a if they appear in R. (Can't use L&~R because there is no way to implement ~R. Can't use L-R because we need ""-R as a way to handle negation.) / How about adding support for ":let