Wishlist

This wishlist is rather outdated, in that several of the items mentioned have already been implemented, or patches are available. If you want to revive a discussion on a particular feature, the best way is to do that on one of the mailing lists or on Niki. The list below is one Mark Edel sent to the discussion list.

Little or no controversy

1. Awk-style associative arrays for macro language
2. Font-selector should detect scalable fonts (size 0) and make them available at any size.
3. Key binding needs in NEdit is way too complex, and Motif menu accelerators have silly problems with num-lock/caps-lock. NEdit should have a unified system for key-binding, spanning what are now shell/macro commands, accelerator resources and translations, and a nice dialog for key binding to existing macros and actions.
4. Macros and actions should be unified and integrated so there aren't two classes of callable subroutines. Users should be able to bind arbitrary macro code to a key without having to define a menu item.
5. Break up the .nedit file into a .nedit directory, so that parts can be more easily modified independently. Maybe a new syntax based on the nedit macro language, rather than X resources, would be better, as well, because it would allow better integration of macro vs. preferences initialization. It would be nice if the macro language could add and remove menu items, and read and modify all preference settings. I'm still a bit fuzzy about all of this, though.
6. Better compiler integration. Most users would prefer tighter integration of the compile/review cycle in NEdit. Currently, users must select line numbers relatively exactly in their compiler output to jump to the line of a compiler warning or error.

   Opinions vary widely on how this should be done. Because compilers vary in how they present error messages, it is probably impossible to devise a non-programmable scheme that will cover all of them. Some possibilities:

   1. Include a more comprehensive Make macro. To do this properly, the macro language needs to be extended to allow some form of continuous updating from shell command output, such that a list_dialog containing compiler output could show intermediate output as a make progressed. As it stands, a make would be much worse than the current shell command version, because you wouldn't be able to see how your compile was going until it was completely finished.
   2. Improve, standardize, and distribute the programming-tools in the contrib directory, which are separate programs for compile/review, search, source-code analysis tree-display which use the client/server interface to NEdit.
   3. Add programmable filters to Open Selected and/or Goto Line Number, which translate compiler messages (as well as output from programs like grep) into file names and line numbers for a file to open and line to select. User could then select the entire message (in xterm or nedit window) to find the file and line.
   4. Full, embedded compile/review mode (with programmable filters for extracting file-name, line numbers from compiler messages), in the same style as the make browser from the NEdit programming tools. Could also track changes since make, to keep line number references fresh.
7. Paren flashing and Match () command both could use improvement:
   1. Match target should be multi-character, to be able to match /* ... */, begin end, and others.
   2. Paren flashing & match command should exclude matches within comments and quoted strings. This is difficult because what constitutes a comment is language dependent.

   The quick and dirty answer is to use syntax highlighting information, but that means syntax highlighting must be on for the feature to work properly, and it attaches more meaning to the highlight styles than was originally intended. At the moment, the highlight style "Comment" means just draw in italics with a slightly lighter gray color. Hard-coding flash/match code to pay attention to specific styles would make it impossible for users to add additional string or comment styles.

   An alternative approach might be to code comment/string recognition in the flash/match code. Recognizing multi-line strings and comments in some languages theoretically requires unlimited backtracking, which may make this difficult to do without performance penalty.

8. Support for special features of CDE, Gnome, and KDE environments (turned on by default when it doesn't interfere in other environments, conditional when it requires special libraries or creates problems at runtime for other systems.
9. Search and Open should have watch (busy) cursor, because under some circumstances, these can be lengthy (due to complex regular expression matching, or remote-access file systems). Ideally, search should also be interruptable (making regular expression search interruptable is probably quite difficult).
10. Some form of multiple-cut-buffer. X has a convention for this, but other programs don't use it, so there's not much need for interoperability. If I recall correctly, the X mechanism is server-memory based, in which case using it would be a bad idea, since it would waste server resources when NEdit is not in use.
11. In syntax highlighting, many pattern authors have asked for the ability to have a sub-expressions from a beginning re-match available in the ending expression, to match special verbatim fields in tex, perl, and other languages. We got started on this in 5.1.1, but got stuck on the problem of controlling incremental re-parsing. To avoid costly reparsing of huge sections of text on every keystroke, nedit needs to detect changes in the spanning subexpression. At the time, the only options seemed to be: storing the subexpression matches by associating them with a position in the text, or trying to recreate the original match by reconstructing and re-parsing the text as it existed before the change. Both of these would be very complicated.

    Thinking about it some more, there may be a simple heuristic, which doesn't require maintaining or reconstructing the original beginning expression match to determine whether to reparse the entire begin/end range. That would be to reparse the begin range and extract the ranges of the spanning subexpression(s), and compare them with range of the modification that triggered the reparsing. If any of the subexpression ranges touches the modification, the begin/end range should be reparsed. It's still significant work, and the rule has a loophole: A change outside of the spanning subexpression can causes the expression to point to a different, unmodified, range of text. Also there's still not a reliable way to find the start of a style range from the end, because abutting styles are allowed. In practice, I don't think either of these things will happen much, but I would feel better if it were mathematically correct.

12. Improvements in help system. (already under development)
13. A tutorial
14. Make initial window size sensitive to size of file being edited. If the file is shorter than the window, make the window shorter (up to some minimum limit).
15. Command-line highlight/no-highlight option.
16. Use .neditdb to remember window size, location, scroll position, and cursor position.
17. Single icon option (Tried and failed in 5.1, probably not possible).
18. Resource for setting backup file extension.
19. Accelerated scroll-bar arrow button scrolling. Use timer to smooth out scrolling on oddly loaded systems. Begin slow, then accelerate at some threshold to higher and higher speeds.
20. Some kind of option to keep an nedit server running in the background when it has no associated windows.
21. nc -wait option. Tells nc not to return until requested file(s?) are (closed? saved? a finish command is executed? ((closed or a macro command is executed first?)))
22. Make pointer disappear during typing (until next mouse movement).
23. Show-whitespace mode. NEdit draws something in the character cells to show what white-space is composed of. Should differentiate tabs from spaces. Maybe, separate show-tabs-only mode might be useful too, but maybe that's too many options.
24. Open Selected include-command format should be programmable so it will work with more languages (also see #3 in compiler integration, Open Selected would also be expected to translate error message formats).
25. Dialog when Find Definition doesn't have a selection, or the selection is not found, to allow a name to be entered.
26. Dim inactive commands in read-only mode.
27. Various improvements in file-dialog behavior. NEdit has taken the Motif file selection dialog about as far as it can go without re-writing, but re-writing could make it much nicer. Possible improvements: moving the previously opened files list there, allowing multiple selection of files, better default sizing, and overall, a more sensible interface.
28. Use inode comparison, rather than path-name comparison to to determine whether a file is already being edited. I know that someone once showed me a case where name comparison fails (possibly with ClearCase?), but I can't find the mail. Anyhow, inode comparison is definitely cleaner than translating symbolic links. There may be some contributed code for this.
29. More preference settings need to be macro-settable.
30. Macro-callable multiple-entry string_dialog.
31. Macro-callable file selection dialog.
32. Load and Save macro hooks, to allow users to add various warnings, translations, etc.
33. Text-modified macro hook
34. Macro function to iconize a window (to allow users who want the single- window editing style to emulate it with macros).
35. C/C++ smart-indent should trigger re-indent on recognition of "case:", and public:, private:, etc. in C++.
36. Action routine and binding for jumping between panes in a multi-pane window.
37. Do something intelligent with stdin. Ideally, open a window with a cancellable (macro?) process, transferring stdin data into the window, until stdin is closed.
38. Macro -> Repeat -> last command should coalesce inserted characters as undo does. Repeating the insertion of a single character is not the most useful default case.
39. Ability to determine language mode from file name via prefix or regular- expression, in addition to suffix.
40. Option to list full path in window title and possibly windows menu
41. Split window mode should align text in lower panes to where it fell naturally before the split, rather than starting new panes both at the same position as the parent pane.
42. Smart indent macros for more languages.
43. New Untitled windows should inherit path from their parent window (I think).
44. Preferences menu settings for background and plain foreground color.
45. Color picker in Text Styles dialog for syntax highlighting (I have a few GPL'd candidates sitting around).
46. A chown of a file can also cause the readonly status to change, and nedit should detect this.
47. Add default macros for Open URL and Grep-browser to default macros.

Some controversy

1. Emulation of other editors. It would be nice to have key bindings a few other editors. Some of these bindings might need additional internal support to work more smoothly. Unfortunately, the current key-binding environment in NEdit is complex, and whole-scale re-binding of keys combined with the odd functionality required by some editors (Advance/Backup in EDT, command mode in vi, multi-key/command mixes in emacs) makes this difficult. Probably better to upgrade the key binding situation first.
2. Native Windows, Mac, Qt, Gnome versions. This would be very nice, but I'm guessing that it would also be quite difficult. The problem is not the text widget itself, it's re-creating all of the supporting dialogs, and all of the subtle shortcut functionality that took so long to develop for Motif. Fully supporting Max's extensions for running in the NT/Windows environment with an X server might be be reasonable, though.
3. NEdit's vi-style Mark/Goto Mark commands are kind of clumsy. I originally wanted to do fully-labeled marks, with a sub-menu for locating marks in the file. The Macintosh MPW editor did this very nicely. In MPW, the Mark command presents a dialog with the selected string entered, by default, as the mark name, so the user types only a few keystrokes to create a named mark, and can go there by simply selecting it from the menu. It helped that on the Macintosh, the marks were maintained across editor sessions in the resource fork of the file, but nedit could save them in the .neditdb file.

   I also like the idea of MS Visual C++ style, which is to have visible marks which you step through with Next/Prev commands. Which is best?

4. Backup-file-exists warning. Backup files are left either because of simultaneous editing, or because of process termination, which makes this a kind of schizophrenic function. Backup files don't exist until you actually do a certain amount of editing in the file, which means it's not a perfect indicator of simultaneous editing (and opening backup files early before users do any editing, to make them better indicators, would increase he likelihood of orphaned backup files).
5. Ability to collapse blocks in outline form, as in the Scriptum editor and others. This would be great, but I think it would be difficult to do in a language-independent way. Also, the basic organization of nedit's drawing code is to fetch and measure text as necessary for drawing, and hundreds of fetch and measure operations are scattered throughout. This would be a change to the basic structure, and therefore very difficult.
6. Tear-off menus should be independent of the window from which they were torn-off. There are two technical and one user-interface problems which need to be solved before this can be done properly:
   1. The X window manager protocol, as far as I know, does not have an adequate model for windows which float above a group of other windows.
   2. To make tear-offs truly window-independent, you probably can't use any of the Motif tear-off code. Motif has a strongly embedded need for parent widgets. You can't fake-out or re-parent the tear-offs when the window they were posted from goes away. They must be independent entities.
   3. (The ui problem) Most menu items are editing operations, which must refer to a particular window/file. How does NEdit decide which window to act upon when a torn-of item is chosen? The last window to have focus? In this case, pointer-focus users had better watch out where they move their mouse on the way to the menu.
7. Tab stops at arbitrary positions. I'm not sure there's much need for arbitrary hardware tab-stops, given that the tab-stop data can't be stored as a part of the text file (maybe if you were still using an old mechanical teletype). However tab-stops in combination with emulated tabs would be helpful to people laying-out columnar data. Making NEdit draw text using tab stops is probably not that hard, but the user- interface parts for entering the stop positions probably is, because ideally you would want something like MS-Word's tab bar at the top of the window, where you could drag tab-stops in and out.
8. Go-back to last search-position, last cursor-jump (more than one line of movement or scrolling)
9. Integrate Tony Balinski's range set macro extensions for highlighting arbitrary areas of text. I'd like to find a way to make this functionality easier to use and easier for users to understand. Just hiding it in the macro language doesn't really solve the problem. If we did provide default macros for multiple-find and highlighting differences, users would need to learn to control the coloring to properly use them.
10. Some kind of file-comparison (diff) mode, for scroll-locking two (or more?) files together (and highlighting differences?). (see above)
11. Some sort of find-all command to find all occurrences of a string. Display would be in some sort of alternate highlight mode (see above), or in a pop-up window showing all matching lines.
12. Environment variable or resource for setting an explicit backup directory.
13. Search and replace dialogs operating in Keep-Up mode should warp pointer into dialog on new Find or Replace command (and/or do something else to attract more attention to the dialog box).
14. A dialog for changing file protections (including access lists?). Can this be made relatively system-independent? Is this beyond what an editor should do?
15. Should commands with optional [Shift] modifiers be somehow marked more clearly so that the effect of the shift key is clearer, i.e: Find... [Rev] Shift Left [Tab]?
16. Make inter-line spacing settable (is this worth an additional resource?)
17. Do multi-line overstrike pastes as overlay. User suggested looking at how Windows '95 text fields handle overstrike paste.
18. Should pointer cursor change to I-beam? If it did, it would nice to generate this on the fly to match the font size somewhat.
19. Highlight styles don't have a selected foreground color, or a background color. These might be useful, though they obviously require specifying a lot of colors.
20. Optional tool-bar (personally, I hate these). Must be done by someone who is either a good graphic designer, or who knows a good public source for high-quality bitmap icons.
21. Make syntax-highlight pass-1 cancellable, for the case where a humongous file gets opened with slow highlight patterns (I don't think this is easy).
22. NEdit can't edit files with names beginning with + or - (of course just about everything else in Unix rejects them as well). A -- (end of arguments) keyword, after which all items are files would allow this.
23. Next/Prev Window command for cycling through window list (could this be done as a macro to keep menus simpler?)

Much controversy

1. Single-window mode (w/ emacs-like buffer switching), possibly multi-pane with different files in different panes of the same window. This is highly requested, but I am personally against it. If you have a decent window manager and a system with reasonable performance, there should be very little substantive difference between working with multiple windows and working with a single window. Implementing a single-window mode would add menu items, and confuse the interface for everyone else.
2. Max's Clone-window code. I know everyone likes this, and it's even relatively well tested now. It changes nedit's internal architecture quite a bit though, and in my mind, makes the code less maintainable. (though, I guess having two separate versions of NEdit makes it less maintainable too).
3. Save Selection As... I don't like this, because it's a semi-redundant menu item. In the few instances where it would be useful, you can just create a new window and paste the contents you want to save.
4. Save to selected file-name. I'm not sure this merits an additional menu item since you can use Save As... and paste the file name into the dialog.
5. Append command or append option in save-as dialog. There are lots of existing ways to append files both inside and outside of nedit. I don't think this merits the additional menu items or buttons.
6. Option to turn-off control character representation.
7. Remote editing via ftp (Open FTP). Technically, this is easy to do, except for the almost infinite creeping featurism of the gui dialog for accessing remote files. How many users would it benefit, though?