New Editor

Interesting to see so many wanting multi-level undo and keymapping – to my understanding these have been available for several years in TextEditorUndo and MagicKeys. I guess it just goes to show how important it is that Cincom integrate good things into the base rather than leaving them as goodies.

I think we should separate the code editor and text editor requirements. Code editor improvements please us developers, text editor improvements can make a significant difference to user acceptance.

Generic

-- from James: remember where I am - if I have N editors open in workspace tabs, I'd like them to maintain my position as I switch tabs [probably actually a general subcanvas / tab view problem, but I too feel it most severely in the Workbook and tabbed browser (RBTabbedToolsets)]

-- integrated ExtraEmphases

-- modern find/replace dialogs (Heeg has some improvements)

-- modern (i.e. post 1995) font selection. Let us choose the platform font directly, remember that choice but also the FontDescription, and next time if the font isn’t found find the closest based on its FontDescription

-- distinction between tab, Ctrl+tab and Ctrl+I, so I can apply italics in a text field, insert tabs, and also tab into and out of it

Code editor

Personally I don’t feel much need for better code editing functions. Most of those I need in other IDEs and aren’t present in VW, aren’t needed in VW – e.g. code folding.

-- indent and unindent with tab/shift-tab

-- integrated RBTabbedToolsets

-- History and Back/Forward while following a Senders/Implementors chain. Each navigation along the chain replaces the current contents of the editor, and adds itself to the Back/Forward chain as in a web browser or Trippy. ThreePaneSelectorBrowser had good elements of this.

Text Editor

-- import/export from RTF and HTML (Heeg has something for this)

-- support for different height characters in a line / lines in a paragraph / paragraphs in a text

Cheers,

Steve

Why does Microsoft still include notepad.exe with Windows? It is because it is a no frills editor that everyone needs. I use a VW editor for the same reason. I don't need an editor that tries to copy/paste tags; in fact, I paste to VW editors to strip all that junk off before copying to one of Microsoft's editors that attempts to do everything and messes up the hidden tags in the text.

A "modern" editor is one that is configurable from dirt simple through VW enhanced to user customized. I suggest defining an abstract superclass that implements generic editor behavior that others can subclass and override to customize for their own needs. A no frills editor should be one of those subclasses. There should include configurable purpose-based subclasses too; like, "CodeEditor" versus "WorkspaceEditor". I don't want a workspace editor that attempts to add color syntax emphasis, but perhaps someone else does.

A typical scenario would be that menus would be added by multiple frameworks to the "CodeEditor". Each framework should only need to define the menu in one place even though the "CodeEditor" may be configured to actually be anything from no-frills to user customized. In other words, use the Bridge pattern and double-dispatch.

As a tool vendor, don't attempt to be everything to everyone; rather, provide a foundation upon which anyone can customize and share customizations. I'd want the no-frills editor, thank you. IMO, Microsoft fails with editors because they attempt to have full control of being everything to everyone. Every feature MS adds ends up having bugs. Every "assistant" from paperclip to selection assistance end getting in the way. Then consider that OpenOffice does a better job actually being everything to everyone because a release is more about managing integration and protocol rather than managing development.

Cincom should evolve an editor framework that others can extend. Cincom should not need to define all the features that everyone wants, but should integrate popular features and adjust the framework to enable others to extend it. Make it easy for others to use, extend, and share.  Always allow no-frills editing for those that prefer that. Also allow someone to download and install a popular set of editor behavior as their DefaultCodeEditor. Frameworks that extend DefaultCodeEditor (through registered modules rather than method overrides) should continue to work regardless of the editor customizations. The current use of pragmas to extend menus is already somewhat like this.

Imagine that the DefaultCodeEditor has a sequence of user-selectable modules that define behavior. If more than one module attempts to be responsible for both 'syntax highlighting' and 'text selection' rules then the module sequence determines which module gets each responsibility by default. The configuration screen for DefaultCodeEditor should list all the applied modules and the responsibilities that each module would like to control. The user can change the module sequence and also de-select a responsibility of a specific module so that behavior goes to the next in the sequence. Some modules would allow customization of the responsibilities that they have; the configuration window could participate in that configuration too.

Paul Baumann