EditorApi

Editor Plugin API

<span style="color:darkgreen;">by Nuklear Zelph</span>

Due to more thought and some new ideas the old design of the settings dialog that where outlined here are no longer applicable. Instead the settings dialog will be part of the editor "Master Plugin". A generic interface to the various settings will be supplied for the specific editor plugin to handle.

The general tab will be a set of key-value pairs that will automatically be stored in the editor section of the configs. "Highlight Current Line" the "caret" and "right margin" sections will remain, leaving the various settings in the above area to be added freely.

The display tab will probably remain the same and those settings can be access by the plugin via configs.

The syntax highlighting tab will remain as it is, however the example code will be supplied by the compiler plugin. A generic set of coloring settings will be updated in the editor section of configs.

The default code tab I don't understand enough to know what to do with at the moment. I suspect a set of default codes can be stored in the users settings based on language and toolkit they are associated with.

The class browsing tab depends on how that is handled. I suspect it will be a plugin, perhaps a panel adding mechanism needs to be added to the editor dialog or it should be moved. Unless we build a similar built-in browser for C++.

The plugin will essentially supply a list of settings that it supports for the general tab. The dialog will automatically add a scrollbar if the check boxes wont fit on a single page. Each setting will be passed as a pair, a name for the dialog and a config-enry that the editor can read from. Similarly the display and syntax pages will have a fixed set of entrys that can be read from. Each time the user closes the dialog, the editor will be sent a message telling it to read in the configs for changes.

The editor itself can decide how it manages syntax highlighting, bookmarks, breakpoints, error lines and the like. It will only need to read the various settings from configs in a standard way.

There will be several sub-API's to interface with the plugin. This way the editor component used internally will not matter.
Selection API, for updating or retrieving the current text selection. (some may support multiple selections 6as well)
Text access/manipulation API, the core of the editors capability.
Marker access API, this one allows any plugin to access and modify any sort of markers, highlighters and folding. The compiler and debugger plugins will have a special access area that other plugins cannot access, these will be generic. This way error lines, breakpoints and such can be managed without interference.

The editor plugin will have a type entry that will let third party plugins know which editor component is in use. This way plugins can know if they will be compatible. a certain set of markers is expectable, but not all editors are likely to have the support Scintilla does. folding will be a generic API, however the editor may not support it in which case all calls will fail. An entry should exists to tell plugins if folding is supported. Syntax highlighting and compiler/debugger markers as well as user bookmarks are expected in any plugin, if they don't exist the plugin will be considered broken.

Multi-selection will be supported in the official plugin. Probably manual highlighting of text selections as well. Once the NZTextEditor spell checker plugin is built it will be added as an optional plugin, probably enhanced some for checking comments and what not. Also a JavaScript plugin will be created for NZTE, probably something will be built based on that as another plugin.